jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Tree model
Date Tue, 28 Feb 2012 17:21:13 GMT

On Tue, Feb 28, 2012 at 5:34 PM, Thomas Mueller <mueller@adobe.com> wrote:
>>>So far we used the MicroKernel API (JSON / JSOP API) on the low level.
>>I'm a bit worried at how complex the current MicroKernel interface
>>already is.
> I don't think the MicroKernel API complex. java.util.Map alone has more
> methods.

There's more to complexity than method count.

I guess you'd agree that the MicroKernel API covers a lot more
functionality than the Tree/Leaf interfaces I drafted. Someone
implementing the MicroKernel needs abstractions like Tree/Leaf and a
lot more besides. In the org.apache.jackrabbit.mk.model package that
abstraction is currently the Node interface, that is actually more
complicated (in terms of having more responsibilities) than the
Tree/Leaf API I'm proposing.

> But maybe you want to discuss this with David and Stefan who
> drafted this API. In my view, the MicroKernel API is relatively simple. It
> is good for remoting (batch operations). Also, it's possible to implement
> a MicroKernel implementation in C or so.

Let's not get tied up about MicroKernel. The Tree/Leaf API I drafted
is explicitly *not* meant to be an alternative to that interface.

> We have two MicroKernel implementations that deal with storage, and I
> don't see how a java.util.Map would help there. For other implementations
> (for example a Virtual Repository) it might be OK, but I don't immediately
> see the advantage.

I see two main advantages:

a) With a shared tree model, alternative MicroKernel implementations
could be sharing a lot more code.

b) A minimal and well-documented interface for such a key concept
provides a solid reference and extension point for the rest of the

>>JSON parsing and formatting,
> As I wrote, this is optional. It is not required when using the wrapper
> API (see my previous mail).

I think it's a sign of design trouble when you need a separate API for
wrapping another.

Also, if you look at the VirtualRepositoryWrapper class in the
.mk.wrapper packag; that's a whole lot of JSON handling going on.

>> path traversal, etc.
> This is anyway required, even when using your interface.

Nope, the Tree interface explicitly has no concept of a path. Paths
need to be parsed and interpreted in a higher level basically by
calling get() on each patch segment after possible namespace
processing. AFAICT there's little reason for why such path handling
should be done by the storage layer.

>>Not to mention the
>>completely unrelated responsibilities like getHeadRevision() or
>>waitForCommit(). The proposed Tree/Leaf API avoids all that.
> I can't comment here because I don't understand what you mean.

Changing the example a bit to make the benefit clearer: Say I want to
implement a new caching layer that uses some custom algorithm for
caching repository content. Such a layer only needs the ability to
intercept read access to repository content. Why would I need to
implement a method like waitForCommit() in such an extension? And on a
similar note, why would such an extension need to know about JSON
formatting or be able to diff content trees?

To summarize my point, if we're going to be working as a team both
above and below the MicroKernel API, we need more tightly focused
abstractions for being able to better coordinate our work. Otherwise
we'll just continue down the path where everyone has their own
MicroKernel implementation.


Jukka Zitting

View raw message