jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: Less flexibility
Date Fri, 29 Jun 2007 14:30:55 GMT
Hi Jukka,

I agree that these internal interfaces - particularly PeristenceManager
comes to my mind - we initially created to solve problems at a very early
stage of Jackrabbit development. Later they gained momentum and span off
their own life in a way, they were never intended to be used. As such, I am
particularly concerned with these interfaces, that they constitute some kind
of de-facto API (as opposed to the real API in the o.a.j.api package or
javax.jcr as a whole) but never have been treated as API. Fortunately
though, they remained relatively fixed.

I agree to seriously consider these internal interfaces and look at their
value nowadays. Yet, if it is decided to walk away from them some kind of
backwards compatibility may certainly be built using some bridges -
performance is probably not the primary goal in backwards compatibility

Yet, another problem you are actually bringing up is the configuration of
Jackrabbit at large: I think the current way of configuring Jackrabbit is
not flexible enough and needs a rework, too (hasn't this been said before
:-) ). Maybe your concerns (apart from the PersistenceManager problems) is
mainly an issue of how configuration is taking place ?

Just my €.02


On 6/29/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> 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
> solution.
> 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
> anymore.
> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message