jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <christ...@sulu3000.de>
Subject Re: Less flexibility
Date Fri, 29 Jun 2007 21:16:03 GMT
Jukka Zitting wrote:

> * 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.

Hm, what do you suggest instead? AFAIK those two work quite different and there 
needs to be some interface between persistence and ISMs. So you need to have 
some kind of layer for one of them. Maybe it would have been better to introduce 
a new interface which uses the bundle pm "natively" and a wrapper from that 
interface to the old pm 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.

I agree that it is quite cumbersome to try to be as generic as possible here 
assuming that there will be not other implementation of SearchIndex anytime soon 
if at all. But I think it's good to have all the lucene stuff separate from the 
rest of the query subsystem. Actually I think a lot of Jackrabbit is too tightly 
coupled to efficiently write unit tests.

> * 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).

I like the FileSystem interface because it enables us to use a memory based file 
system for tests for example. What I don't like is the fact that it is not 
consistenly used throughout Jackrabbit because this makes the interface useless.

> 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. :-)

Well in most cases we could probably come up with some backwards compatible 
wrappers. Backwards compatibility shouldn't be the limiting factor. May be we 
should deprecate some of the old things like XmlPersistenceManager etc. to make 
it easier to provide backwards compatibility.

I think all the points you mentioned were good decisions from an architectural 
view. Do you have any specific change proposals regarding the configuration? How 
would an ideal configuration look like?


View raw message