Hi, Replying over all to this thread..
My take is, that we try to create such separate projects right from the start. Yes, I am already thinking in Bundles. But having separate projects also makes it easier to really keep separate things separate. I mean, it is impossible to polute some code with a dependency on another package which exposes implementation details (see for example the NodeId parameters of Jackrabbit 2 PersistenceManager interface). Yes it makes development a bit harder at the beginning -- but maintence will be a lot easier. Also, if the package space is properly separated between the modules, it is much easier to find the correct location of code. The problem with Jackrabbit 2 is, that this package space is not properly separated and that some package expected in the one module is actually in a different one (for example the jcr-server module hosting "webdav" packages which would be expected in the webdav module). And yes, I would create a MK API module separate from the Oak default MK implementation. As I said elsewhere this helps other implementations as well as providing testcases to validate MK implementations. And yes, I would create a proper/separate Oak SPI, which is optimized for communication between the transient space implementation part and the actual Oak implementation part. Again having a separate Oak SPI module would help separating API from leaking implementation detail and help build validation tests. Regards Felix Am 09.03.2012 um 03:58 schrieb Jukka Zitting: > Hi, > > Following up on OAK-5, where the question came up on whether we should > put the JCR binding for Oak to a separate oak-jcr component or just > under an .oak.jcr package in oak-core. There are good arguments for > both approaches, and the balance of the different solutions also > depends on the state of the overall architecture. > > Before making the decision on this, here's a few questions to consider: > > 1) What's the main API through which functionality in oak-core (and > the potential low-level extensions it interacts with) shall be > accessed? Shall things like node type handling, versioning, locking > and query support be included in that API? AFAIUI the MicroKernel > interface is intended more as an internal extension point and remoting > API instead of something that a client (including one like a specific > protocol binding) would directly interact with, so it probably > shouldn't be the API through which other components access > functionality in oak-core. > > 2) What kind of clients will interact directly with Oak through JCR > vs. some lover level API (call it Oak SPI for now)? For example, do we > want to build a WebDAV or JSON/JSOP protocol binding based directly on > the Oak SPI or should they work on top of the JCR binding like they > currently do in Jackrabbit 2.x? Using an appropriate lower level API > might make it easier or even possible to implement things like ETag > support for WebDAV. > > 3) Given that such an internal Oak SPI is needed above the MK level, > are we confident enough that we know where that boundary between > oak-core and the proposed oak-jcr components should be set and what > the boundary should look like? Making a premature decision on that > could easily become a self-fulfilling prophesy that binds us to a > specific architectural layout. For example the current Jackrabbit SPI > has some inherent design limitations that are very hard to fix anymore > given that plenty of client code is already using it. > > BR, > > Jukka Zitting
