Hi, >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.
I'm not sure what you talk about... is it about the IndexWrapper, LogWrapper, SecurityWrapper, VirtualRepositoryWrapper, and Client? * LogWrapper: I believe it is useful in any case. * SecurityWrapper: I guess will not be needed (depending on who you ask :-) * VirtualRepositoryWrapper: currently not needed (I think at some point we will use it, well let's see). >The MK covers quite a >bit of functionality, from basic stuff like JSON parsing and >formatting My hope is that the same code could be used in the MicroKernel implementation and the MicroKernel client (Oak Core) >to complex topics like clustering and handling of merge >conflicts. Clustering is currently not needed I believe. Merge is only handled in Stefans implementation. > Do we want each MK implementation to have their own >implementations of these things For JSON parsing: I think no. For DataStore: I think no (my view). Everything else: it probably doesn't make sense to try to share code, as it would make one implementation depend on the other implementation, which doesn't sound right (why should the LogWrapper depend on the some other MicroKernel implementation). >, or would it make more sense for a >single shared MK "framework" Shared code should be shared where possible, but I wouldn't use the term "framework" for that... > to have internal extension points by >which it can be deployed in various different storage and clustering >configurations? I don't actually know what you refer to here. We don't have a clustering configuration right? Regards, Thomas
