jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 14:29:17 GMT

On Thu, Mar 15, 2012 at 2:17 PM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> On Thu, Mar 15, 2012 at 1:57 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Yep. I'd like to see that default MK be as simple as possible, ideally
>> just an in-memory implementation designed mostly for testing and as a
>> reference point for other implementations.
> well, i don't understand why you would want to limit it
> to a mockup impl. in jr2 we do have a default pm
> which is readily useable.

Scrap my idea from above. It was going off on the angle of keeping the
MK API (but no significant MK implementation) in oak-core, but it
looks like that idea won't fly.

>> Note that we can (and should) version the MK API package independently
>> on the OSGi package export level. There's no need for the API to
>> reside in a separate component for that.
> i am not convinced. i would still prefer a separate component.

OK, so let's have a separate oak-mk component for the MK API.

More generally though and as discussed a bit already earlier, I'm
still not completely convinced that we'd need (or want) different
implementations of the *entire* MK interface. The MK covers quite a
bit of functionality, from basic stuff like JSON parsing and
formatting to complex topics like clustering and handling of merge
conflicts. Do we want each MK implementation to have their own
implementations of these things, or would it make more sense for a
single shared MK "framework" to have internal extension points by
which it can be deployed in various different storage and clustering

With that concept, the oak-mk component would contain not just the MK
API, but also the default implementation and a set of extension
interfaces by which different storage, clustering and other parts can
be plugged in depending on the deployment.


Jukka Zitting

View raw message