jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Less flexibility
Date Mon, 02 Jul 2007 09:21:02 GMT
On 7/2/07, Miro Walker <miro.walker@gmail.com> wrote:
> Jukka,
>
> I like the idea of making things less configurable (although only if
> it's still possible to configure things the way we need them! :-)).
>
> One area that I've always felt JR is too flexible is around use of
> different configurations for different workspaces. Maybe I'm missing
> something, but I've never been able to understand the value of having
> the versioning backing store on a database and the workspaces that are
> being versioned on a filesystem. Is anyone actually doing this?
>
> We're constantly seeing problems with this approach (corrupted
> repositories, etc.) because there's no true atomicity in versioning
> operations - perhaps if they all used the same backing store (i.e.
> same database connection) then it would be much easier to have them
> committed as part of the same transaction.
>
> How about other configurations? Is anyone out there actually making
> use of the fact that each workspace.xml is based on the
> repository.xml, but can in theory be changed? We never change them

i am ;) it allows e.g. me to migrate data from one pm implementation to another
by cloning the workspace.

cheers
stefan

> after creating them, but still have to dance through all sorts of
> hoops to, for example, change the database connection settings for the
> whole repository.
>
> I guess all these questions are hard to answer without knowing more
> about what's deployed in the field. Perhaps a good way to approach
> this would be to canvas users for what configurations are really
> useful, and then consider retiring those that no longer have a good
> case for them?
>
> Cheers,
>
> miro
>
>
> 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
> >
>

Mime
View raw message