08 September 2006

Java and CMS

I mentioned rather briefly my interest in Java-powered CMS (here). There are not many wiki engines written in Java, possibly because it's more demanding. Java is a program run by the web browser, which take is responsible for converting available data into a readable webpage. My impression which could be wrong, is that interactive webpages are more robust and less prone to unintended results when loading, since they are designed to actually interface with the web browser's virtual machine. In contrast, programs like PHP or JavaScript are designed to create another layer of interface by prompting the website's host to generate a page.
(I tried to discuss this in the prior post on CMS applications linked above. Basically, most CMS applications either generate static pages, which are created as stand-alone HTML files; or else they follow the database format, in which case every single distinguishing trait of each page in the website is saved in computer memory as a field in a database record. The later design is usually more efficient in terms of memory and searching, and is essential for very large sites like Wikipedia. In either case, however, the CMS application that powers the website must generate a file--temporary or permanent--that is read as HTML.)

Another reason why Java-based CMS's might be better is that they do not actually launch a server process whenever the user interacts with the application. Supposing it is a WikiEngine, for example, which is accessed by a large number of users. Each time a user wants to preview her new post, for example, the CGI application is required to launch a new process. But the Java app will only need to launch a new thread.

CGI versus Java: not a valid comparison!

It has to be pointed out that the dichotomy between CGI and Java is not valid. CGI is, after all, an open application programming interface (API); Java is a programming language. One can create a CGI application that is powered by Java, although this is not common. Generally speaking, Perl or PHP is used for programming CGI applications; Java applets are used for programs that run off the visitor's web browser.

However, in researching this essay, it became apparent that Java (unlike Perl or PHP) can replace many of the functions of a CGI application, while executing those functions in a way that is, in some ways, preferable to (and logically exclusive of) the CGI API. Conversely, most CMS's that are in common use were created in Perl or PHP (not Java!) because they are easily understood by people with a casual familiarity with HTML. Also, it is often unnecessary to have a costly Java application when mere HTML with a little JavaScript will do fine.
There are quite a few Java-powered WikiEngines, mostly of the database-orientation. Courtesy of WikiMatrix, I am aware of Clearspace, Corendal, Ikewiki, JAMWiki, JSPWiki, SnipSnap, and XWiki. In addition to these named, there are some systems developed for large organizations, such as SamePage, which I have ignored. XWiki (samples) seems to be oriented to professional developers, and I don't think it's really feasible for my purposes.

Ikewiki is a semantic wiki developed in Salzburg, Austria. Semantic wikis (SW's) differ from the usual type in that they have a peculiar logical structure of the data. So far I have found no implementations.

Examination of wikis created from these engines has been extremely time-consuming, but let's make some quick notes. Clearspace is a commercial product ($29/user) from Jive Software. It's evidently used in the BBC's website, TechRepublic forums, CNET forums, and Amazon.

JAMWiki is an interesting concept: it's a WikiEngine with feature parity to MediaWiki (the most commonly implemented of all, and used with Wikipedia). So far, the selection of implementations is very slim indeed. Janne Jalkanen created JSPWiki to develop and advertise coding tricks, but it's spartan and specific to the general purpose of JSP.

Labels: , , , , , ,


Post a Comment

<< Home