jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Thu, 15 Mar 2012 16:01:36 GMT

>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

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

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

I don't actually know what you refer to here. We don't have a clustering
configuration right?


View raw message