Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of miro.walker@gmail.com
 designates 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=XxX74vwvum9GgLhhnjvS09rtBvE9p2RRl87ghK35BEq7BpAD24i/e/J4bQKuymCwWuaGFpVplOVNecmM1RiozgC5my5YhGBWRQW+5gcXFLYg9CeMOGvCOt3yON1yrg6MVSlcoCGV/Sjx68rX+zdN/JRgq6j4MI0LnBthiYS8mqg=
Message-ID: <9f929f1c0707020136g5d691abag694f92c578171e3c@mail.gmail.com>
Date: Mon, 2 Jul 2007 09:36:16 +0100
From: "Miro Walker" <miro.walker@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Less flexibility
In-Reply-To: <510143ac0706290718y131bda07lb767b77bd9d9f6a6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <510143ac0706290718y131bda07lb767b77bd9d9f6a6@mail.gmail.com>

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