E2 and LJ, Comparing Content Management Systems
Anonymous Noder/LJ'er writes "Linux.com is running a story written by Slashdot's Krow, one of the authors of Slash comparing the LiveJournal site engine to the Everything2 engine. He went over the installs of the two engines and talks a bit about customizing both. I really like both sites so it is interesting to see someone talk about what makes them tick."
Comments about administration policy asside, I think that comparing the two isn't strictly fair. At least, not on absolute terms.
As a developer on both codebases, teh differences as I see them are basic: Ecore is about grouping and linking as sets, while lj is more about mass indexing of list-type data.
One of ecores main weekness is scalability, or lack thereof -- this is not a slam on teh code, but just an introspection on design. Because lj os more about this loose-linked list paradigm, it can easily scale and cluster on mutliple machine while ecore, with it's extreme data interlinking, is heaving right now with redesigns to allow that.
Of course, Ecore (or at least E2) has a much better XML interface, which is probably it's second strongest point. It's first strongest and most important is the concpet that everything is a node.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Here is the original WikiWikiWeb: http://c2.com/cgi/wiki?WelcomeVisitors
Here is a Wiki you can easily install on your own machine: http://minnow.cc.gatech.edu/swiki/15
Here is a free Wiki farm that let's you start your own on a shared server: http://www.seedwiki.com
Having looked at several CMS for a website I am going to relaunch, I needed an approach that was most general and would allow me to choose how I could store the content and separate the design. OK, the difference to the projects mentioned here is that I don't need a large system to manage things like user comments or other methods of dynamically adding pages. Currently I think I will go with AxKit, which is not really a CMS, but basically an on-the-fly caching XSLT processor. For me this provides the most flexible solution. I have designed an XML format to store my content files, and can then use either an XSL stylesheet to produce HTML or WML or whatever needed, or write an XPathScript style sheet allowing me to process the XML data while additionally using perl code to add dynamic features. The nice thing is that with AxKit you can use HTTP GET parameters to allow different style sheets (plain, xhtml, print, ...), pick a style sheet depending on browser type (lynx, netscape4, mozilla...), etc. And for a website offering mostly static content that needs to be organized in a proper way, I think separating content from layout using XML seems like a good idea. What I like to is that it's easily possible to include multiple language versions of your page in your XML data files and transform to HTML based on, say, a ?lang attribute. Plus, you could even store the XML content tree in CVS...
For websites that are just trying to be in control of their mostly static content, AxKit surely helps (provided you have access to the server box as you need to install the apache module...). Storing pure content as XML and then providing different stylesheets for layout seems a proper way to go for me.
Of course, this is not to say I don't like the LJ or E2 engines, butjust depending on what you need for your website, XML might be helpful, and AxKit might be the way to implement it.
If you are into rolling your own, then take a look at the Look at mod_auth_mysql Apache module. It's basically .htaccess file kind of access control except the user info is in a MySQL DB. So you can do updates/inerts/whatever on the database via your perl and get close to what you need as far as access control without having to write files in the docroot.
You might not be able to make it fine-grained enough, but if you have a thing where each user (for instance) gets their own directory or something then it might work pretty well for you.
And if you are not into rolling your own anymore, check out Moveable Type.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
MS Sharepoint Portal Server is the a next round in MS's binding of the corporate office bureaucracy to them. It's basically a Web CMS and DMS that fully integrates with the rest of MS Office.
It's a pretty damn poor Document Manager, and a really abysmal Content Manager in most respects (except for - again a killer feature - WYSIWIG page editing inclusive of component embedding), but the MS Office integration is the key. And of course, no-one can integrate with MS Office better than MS.
If there was a decent "Open Office Portal Server" then things would be just dandy - but, as it is, Sharepoint will act to lock people into another round of MS-dependency. Sharepoint Portal Server has been used by people talking to me as an argument to stick with MS Office even with the existence of open office and star office.
Choice of masters is not freedom.