Hi, On Tue, Feb 28, 2012 at 5:34 PM, Thomas Mueller <[email protected]> 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 implementation. >>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. BR, Jukka Zitting
