Hi, On Thu, Mar 15, 2012 at 2:17 PM, Stefan Guggisberg <stefan.guggisb...@gmail.com> wrote: > On Thu, Mar 15, 2012 at 1:57 PM, Jukka Zitting <jukka.zitt...@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 configurations? 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. BR, Jukka Zitting
