ActiveMath's wealth of specificity

ActiveMath builds on a heap of specificity… you generalize you either break it forever or spend six months debugging.

It never crossed my mind that I needed to say this that loud but it has been very common to encounter folks that have not started ActiveMath asserting some generic tool X should be used since it does most of the jobs ActiveMath actually does.

Classical examples include the transformation/rendering tasks. This seems to be covered fine by many platforms (e.g. even Cocoon) but the wealth of this rendering lies into the integration: in the quality of the links, in the consistent presentation, …

Another example includes the content storage of ActiveMath. This dark piece is still staying non-understood mostly because it does not rely on hibernate, a classical SQL database, an XML database, or some other modern hype.

It relies on Lucene, and (even worse to the taste of some), it relies on simple files as basis and input. But why not jump on any modern technology ? Most of the times, the reason is performance, the content storage interface needs to answer about 300 queries a second and very few engines do this; another important requirements is to treat streams of very variable length correctly (hibernate does this very badly for example).

The blog entry of Martin RDF-store complements MBase is a good example of such a comment, at least so it tastes. Clearly, RDF-store could bring some oil instead of ICmap making its walk alone within MBase but i feel the interest is mostly for reasoning. RDF-store would be a reasoner, right, that would work. But not a storage! And that reasoner could even start to be a simple port-to-the-server of the ICmap recursive walk engine… But please let us avoid “it should be all converted to RDF and basta” as can be found in many places.

My old simply… ActiveMath’s wealth lies in the integration of the many services, not in the many services it has available. But maybe I am too dark.

Trackback URL for this post: