During this talk we heard about 3 different systems. Here are some quick notes on each.
slash
Story publishing, preferences, Journals, personalization, community moderation and interaction, logging. Not built for manging a large document base--it' more of a community system than a content system. Simple, easy to learn interface. The strucutre is not complex, provides delayed publishing, and RSS feed integration. The publishing workflow model is very straightforward. That can be a problem for sites that really do need something more complex.
Slash stores all content in a database (typically MySQL) and it performs a lot of caching for mostly static stuff. Uses a templating system called TT.
Slash can be extended via a simple API and there are a lot of good examples out there already. SOAP interfaces are coming in future versions of slash, too.
Why slash? Light and simple. Scales well. Great community features. There's even an O'Reilly book for it.
Bricolage
It's very complete and professional, and it covers a lot of ground. Asset (or object) management. Heavier application-like interface with a lot of power.
The UI is very functional and feels very much like a desktop application. Good contextual help.
There are stories, media, and templtes. The three building blocks. The first two are built using elements. Elements may contain sub-elements. Defining elements properly is difficult. Requires real design thinking.
Very powerful workflow, using a "desk" concept. Desks are chained together for form workflow. Every check-in and check-out results in a new version.
Can use SSL and has group-based authorization. Both users and objects are in groups. It's a bit confusing at first, but it's actually rather simple and powerful.
Templates belong to categories. Output channels, many for a single document--useful for co-branding or different formats like XML, RSS, etc. Good API available from within the templates, which are HTML::Template or Mason (very cool).
Publishing distribution (via "burners") is quite flexible too. You can do it in parallel or customized (gzip, sign it, complex upload, etc).
Has alerts that can be triggered based on various events (move, delete, check-in, etc.) The event handlers can do e-mail but will get jabber support soon too.
There's a good SOAP interface. The mailing list is very good. Active support.
Uses a PostgreSQL backend.
XIMIS
Very new, just released. Tied to Oracle now, but moving to use other databases later this year. University of Insbruck runs it. Started as a framework and evlovled into an application later.
XML, XML, XML.
XIMIS == "XML Information Management System"
Uses DOM, SAX, and XSLT. You really have to get in to XML.
Document tree with multiple views where docs are of any type. Different doc types have their own handlers. Some WYSIWYG pulugins for uploads and whatnot. They're not free and only work on Windows. Someone is trying to develop a Mozilla-based front-end.
Very elaborate security system, complex and fine-grained access controls system. Supports IMAP, LDAP, etc. Does inheritance on permissions where needed.
Communication tools. Has a forum and some built-in messaging. Sometimes better than going outside (phone, e-mail, etc).
Internals. Very MVC inspired. Uses CGI::XMLApplication (SAWA, whatever that is). AxKit interaction possible.
Every document is an object. Random data can be attached to objects easily. User interaction generates events.
Style sheets used to transform documents (of course). So, the application gets an event, handles it by manipulating an object, and a stylesheet is selected to render the object. I think that makes sense.
Posted by jzawodn at July 25, 2002 11:05 AM
