Application server evaluation

Important points to consider when evaluating which application server to use include:

Ease of communication between application server and PHP
Application server's community and licensing model
Additional features provided by application server
Suitability for medium-scale deployments

The following table provides quick view to pros and cons about the different application servers evaluated.

	Zope	JBOSS	Persistent PHP	FastCGI
Language	Python	Java	PHP	Perl?
Pros	Full-text search	J2EE	PHP connectivity	?
Cons	?	?	Experimental	?
Questions	i18n?	?	Stability? Installation?	?

2003-03-28: Comments from Alexander Bokovoy

I'm not sure we need to go to Zope or JBOSS as backend server. It is just yet another overbloated solution. In addition, both of them have some tracks for security flaws, and in particular JBOSS use means involvement of far from effectiveness language beneath the scene.

I still think things like CORBA are unnecessary in our framework, they are too complex for our tasks.

What to propose instead? There is a trend which probably will dominate next few years, to reveal information structure and links between information sources. You know a part of that was accumulated around Semantic Web movement but that isn't all of it and personally I think SW implementation (as it exists now) is wrong w.r.t. selected tools -- for example, XML-based representation of it is still not support fully by any library (there are no libraries that do this for existing standard, not counting extensions).

I think -- and several business cases in Russia show that clearly -- that what we actually need beneath our "Midgard API" is graph database, with abilities to solve a number of classic graph problems (subgraph extraction, search for short path between a number of vertexes, and so on). This framework will help to solve more user-related tasks:

automatic determination of relevant links
automatic re-structuring of "views" depending on additional externally injected parameters
automatic discovery of similarities between different subgraphs (or vertexes in graph) -- important for various tasks like extraction of relevant information from many conflicting sources

From existing applications this approach is particulary implemented in Google engine, but not only there.

Another component of such system, which would be really valuable, is fast NLP (Natural Language Processing), including extraction of similar terms/dicussions from a correlated sources. This task is really hard because there is no open source library out there for effective manipulations of finit state automata of various kinds, including fast manipulations of transducers.

I have a friend who works for one of successful companies which deal with NLP and have delivered a number of tools to R&D labs of HP, Daimler Chrysler, IBM, and other such big companies (which led to multi-million savings later). He is willing to eventually implement such library in OSS manner.

Since a complexity of tasks that CMS frameworks are starting to solve is rising every year, I don't think existing tools like Zope and JBOSS would help us to be more competitive on emerging semantic market where all the CMS world will occur in a couple of years.

2003-03-29: Comments from Martin Langhoff

First off, I agree with Alex: I don't like the idea of a separate app server in yet another language. We'd only be adding dependancies, complexity and an XML-RPC/SOAP interface that would have a huge impact on performance and memory consumption.

If we are ready do deal with the memory and performance impact, MidgardLite is our path -- and it is a much simpler and rewarding one.

Ufff. I needed to say that. Sorry, I don't like the JBoss/Zope idea at all. We _have_ an app server, we don't need another.

Having said that, I should describe where I _would_ see Midgard going. Hmmm. My view is much more incremental than revolutionary. Some bold incremental steps can be taken, enough to treat is as a v2, but I don't see a need for a 'complete rewrite'.

First off, eliminate dependancies and simplify installation. Make Midgard PEAR-installable -- make it _simple_. Keep the C PHP extension (can we compile C from a PEAR install? I hope so!) or figure out a cunning way to integrate into PHP nicely.

Try and get rid of mod_midgard. MidgardLite has (I believe) an alternative means of doing it, using only PHP code. Excellent! Let us use that technique instead. If it does entail a significant performance impact, let's keep mod_midgard as the 'high performance' option -- for those willing to deal with the complexity.

Ok, we probably want to keep midgard-data separate. Agreed. Or maybe not. I tend to think it can be distributed with the package, so that installing the package installs a default DB with a default name. And if you want to set up more DBs you re-run configure with a DB name and then run 'make data' to install it. Easy.

It might be tricky to manage that with the RPM/Deb packages. Maybe it should install the DB to the default name, and also install a small script (/usr/local/bin/mgd_install_data.pl) to create new DBs from XML files in /usr/local/var/mgd/.

We can still of course release Data packages separately if we want to provide more granular upgrades and confuse people ;)

In terms of making Midgard more extensible -- I share the idea that we should have more stuff in PHP, but I am unwilling to drop the C layer completely. The fact that we have MidgardLite is a great advantage in that sense.

Why? Because we can hide the API behind a _very_ thin layer of PHP. I imagine all the functions and objects written in PHP, as just a shell over C. Thus we can cheat and change the parameters before calling the C function or after it has returned. Or subclass or extend an object.

Simple, stupid example:

function mgd_create_new_luser {
        // mgdcore_ functions are C core functions
        return mgdcore_create_new_luser()
}

To be fair, I think I have seen a few shell objects built this way by Torben (as part of MidCOM?). This must be part of the distribution -- and anyone can then use and extend the API to suit their taste.

Before I finish with the data package, I have to say that I think it should include several libraries and interfaces, including the PHPmole transport from Alan Knowles, and if there is any reasonably working WebDAV transport.

I also think we need to consolidate on a means to work on files instead of on the database, in particular for snippets, pages, page-elements, styles and style-elements. I haven't yet used the FileSynch package, or filetemplates or anyhing, but let's make sure _one_ of them is solid and workable. Distribution of completed projects or libraries can still be done in XML -- so it doesn't worry me.

Last but not least: we need to rework Repligard. For real.

My current thinking is to implement it in Perl (or PHP) with very good comments and structure, so the flow is easy to follow, and easy to hack-in project specific rules. The key with a Perl/PHP implementations is that it _must_ be able to stream the objects to the file. It is no good to build an in memory image or string to dump later -- that will go splat on our faces. And no, it doesn't need to integrate gzip, we can pipe that on the output.

Allright, there you go. My secret agenda -- laid bare in front of your eyes. Not much more to add -- except that I believe Midgard is "99% good" (to paraphrase Nielsen) and that's why no-one is _that_ desperate to rewrite it from scratch.

Midgard is a great foundation framework to which I believe some incremental enhancements (some bold, some sutble and shy) would be good. The rest, is the building we put on top of it.