Hi,
Given Jukka's considerations I think we should start out with two modules: one for the Microkernel and another for the JCR implementation on top of it.
Regarding the Microkernel: even though we consider this an "internal" interface at this point, the facts that we keep the interface language agnostic and want to use it as a remoting point clearly makes it a separate module.
Regarding the JCR implementation: Even though there most likely will be a further layering (oak-spi) in the future, I think the details are to vague still to make the split now. As Jukka mentioned, we should get a clearer picture on the use cases/clients for such the oak-spi before going forward here.
Michael On 9.3.12 12:58, Jukka Zitting wrote:
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
