On Fri, Mar 9, 2012 at 2:30 PM, Michael Dürig <[email protected]> wrote: >> >>> 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. >> >> >> as far as i understand the overall strategy as presented by >> david at the last f2f in basel the objective was to have a separate >> API boundary (SPI-like). >> >> therefore i would strongly suggest to separate jcr-transient >> space from an "SPI" layer from the very beginning. based on >> my experience both with jackrabbit-core and being the author >> of the v1 SPI i am convinced that we should start with that >> separation from the beginning and force ourselves to clearly >> distinguish between the two. >> we should start with an first proposal of what part of the >> JCR implementation goes where and keep discussing those >> decisions as we go ahead and face problems and inconsistencies. > > > I very much share these concerns. However, I'd rather wait a bit with > separating the two until we have the basic things in place. I think we > should add an extra bullet point for this on the release road map [1]: > > * SPI extension model > > I think 0.3 - May 2012 would be a good fit. > > [1] http://markmail.org/thread/7dhxklytr2xaoe24 > > >>> 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. >> >> >> as far as i understood from the discussions we had so far, we >> have both use cases: >> >> a) applications that interact with the JCR API >> b) applications and non-java JCR implementations like the Jackalope >> project that directly interact with the Oak SPI as you call it. > > > As far as I understood David, his take on this is that SPI is "everything > modulo transient space". So to take a more radical view: why not make the > SPI implement JCR but conceptually add a save operation right after each > transient operation?
why would that be useful? cheers stefan > > >> >>> 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. >> >> >> imo we should not be afraid of creating the boundary right from >> the beginning and feeling free to adjust it as we go ahead. >> but the prerequisite was to have a first draft of what goes where >> that allows us to validate our assumptions and change or >> refine them in the dev process. > > > I'd also be fine with such an approach. But we need to make sure that we > don't lock ourselves into backward compatibility liabilities right from the > start. > > Michael
