jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] Tree model
Date Tue, 28 Feb 2012 16:34:20 GMT
Hi,

Too bad you could not come to the last F2F.

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

>Given the current scope of the MicroKernel interface, I'd see the
>Tree/Leaf interfaces as being internal to the microkernel
>implementation.

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.

>A different discussion is that I think having interfaces like the
>proposed Tree/Leaf exposed also to higher level constructs like node
>type handling would be quite useful. I don't see how something like
>that could easily be achieved with the current MicroKernel design.

OK, if you talk about a high level, it's a different story.

One idea is to use two remoting APIs. The stack is:

[App using the JCR API]
  |
(JCR API)
  |
[JCR implementation, transient space]
  |
(SPI API)
  |
[Jackrabbit including Versioning and so on]
  |
(MicroKernel API)
  |
[MicroKernel Implementation (Storage, Virtual Repository)]

>>>And since it's an interface, we could also implement features like
>>>virtual content without the complexities of the current
>>>VirtualItemStateProvider mechanism.
>>
>> I think that's possible even with the current API.
>
>It's possible, but pretty complicated.

No, I think it's not complicated.

> Just consider all the stuff
>you'd need to implement for a virtual jcr:system tree (like the one we
>have in current Jackrabbit) with the current MicroKernel interface.

We don't necessarily re-built it like it is in Jackrabbit 2.

>JSON parsing and formatting,

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

> path traversal, etc.

This is anyway required, even when using your interface.

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

Regards,
Thomas


Mime
View raw message