jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Less flexibility
Date Fri, 29 Jun 2007 14:18:04 GMT

I think this will be a bit controversial, but I would like to explore
options for making Jackrabbit *less* flexible and configurable.

Currently we have quite a few internal interfaces like
PersistenceManager, QueryHandler, FileSystem, and Journal that allow
you to fully configure various parts of the system. Many of these
interfaces were fixed in relatively early stages of development and
are now having a major effect on how the product is seen and used. We
have actually encountered a number of cases where new components or
alternatives need to go through extra hoops to comply with an
*internal* interface that might no longer be seen as the optimal

Some specific examples:

* Bundle persistence is in almost all cases more efficient than the
previous item persistence where each node and property is stored
separately. But the bundle persistence manager still needs to
explicitly simulate item persistence to comply with the
PersistenceManager interface.

* The fixed SearchIndex interface and configuration model cause us to
implement workarounds for configuring things like the synonym matching
or the new indexing rules (see
http://wiki.apache.org/jackrabbit/IndexingConfiguration). See also the
latest comments on JCR-989, especially in the light that the Lucene
SearchIndex implementation is the only real QueryHandler
implementation we have.

* FileSystem instances are being created and passed around even if
many components either just ignore them (see SearchIndex) or rather
use custom alternatives (see database persistence).

And these specific issues are just the tip of the iceberg, the real
problem is that we seem to be so accustomed to these interfaces and
the boundaries they create that we have trouble imagining what we
could do if they didn't exist or at least were more flexible.

I'm not sure what (if anything) we should do about this, especially
since there are backwards-compatibility issues to consider, but I find
it interesting to consider all the possibilities we would have
available if the only Jackrabbit configuration option that was
guaranteed to be backwards compatible was the repository home
directory. :-)

I guess even if we do nothing else about this it would still be good
to keep in mind that the internal interfaces we have now are nothing
more than internal design decisions that may or many not be valid


Jukka Zitting

View raw message