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?
Cheers, Christoph
