jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 13:20:22 GMT
hi michael

> 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.

i tend to disagree here as explained in my response to jukka.

> 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.

wasn't the very aim of your 2 experimental jcr2x implementations to
precisely get that clearer picture? what was the outcome?

i think the last year should have provided sufficient results
to allow us starting with an Oak SPI. there is no need to
finalize that hic et nunc but we have to start thinking about it.
further delays will IMO not produce better results for designing
an SPI.

kind regards

> 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

View raw message