jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 15:06:38 GMT
On Thu, Mar 15, 2012 at 3:29 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> 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.

great.

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

whenever i see the term "framework" i am kind of sceptical ;).
my usual experience with frameworks is that they're doing
an ok job for the standard use cases but can't handle real world
problems. that's just my personal take of course.

i am all for providing extension points as long as they don't
mandate a general, non-optimized implementation.

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

agreed.

cheers
stefan

>
> BR,
>
> Jukka Zitting

Mime
View raw message