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
