On Thu, Mar 15, 2012 at 3:29 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > 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.
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
