Re: On setting component boundaries in Oak
hi jukka thanks for the summary To expand on this a bit, here's more detailed diagram that attempts to identify key APIs (green boxes) and main implementation components (violet boxes): http://people.apache.org/~jukka/2012/oak-components.png looks basically good The API and protocol bindings on the top are just some examples. ok... because i am not so sure about a plain WebDAV binding. imo that one would rather belong on top of the JCR binding. so, i would rather not have listed here as long as we don't really plan to build that as it might cause confusion. We can have any number of such components working (simultaneously) on top of an Oak repository. agreed The microkernel implementations at the bottom on the other hand are exclusive. A given Oak repository instance uses only a single microkernel implementation, though different repository instances can obviously run on top of different microkernels. The middle part of the diagram, ranging from the Oak API (using a different term than SPI to avoid confusion with jr2) through the Oak that sounds reasonable. repository implementation to the underlying microkernel API, is in my view the core part of Oak. It forms the core framework that's present in all repository deployments, regardless of which bindings or other clients are present and which microkernel implementation is used below. Since according to this overall architecture there's a 1-to-1 connection between these two APIs and the implementation in between and since they together form the core of a repository instance, I think we should (at least for now) keep them together the a single oak-core component, as shown in this diagram: http://people.apache.org/~jukka/2012/oak-components2.png well... but this means that the mk implementations that are currently located in the oak-core module should be moved out to some different component. and if we do that i don't really like the idea of having the MK-API being part of the oak-core module as it requires MK-implementations to have a dependency to oak-core including the API... that looks odd to me. so, imo we should rather keep oak-api (aka spi) and the mk api/impl separate. that would lead us to start with 3 components that identify the layers and make the dependencies very clear. The oak-jcr component that I also identified in the above diagram would only contain the code needed to adapt between the Oak API and the higher level JCR API. makes sense. and again: oak-jcr needs to have a dependency to the oak-api but should not deal with MK... having a clear separation dependency-wise would be favorable here IMO. kind regards angela BR, Jukka Zitting
Re: On setting component boundaries in Oak
Hi, On Thu, Mar 15, 2012 at 2:17 PM, Stefan Guggisberg stefan.guggisb...@gmail.com wrote: On Thu, Mar 15, 2012 at 1:57 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Yep. I'd like to see that default MK be as simple as possible, ideally just an in-memory implementation designed mostly for testing and as a reference point for other implementations. well, i don't understand why you would want to limit it to a mockup impl. in jr2 we do have a default pm which is readily useable. Scrap my idea from above. It was going off on the angle of keeping the MK API (but no significant MK implementation) in oak-core, but it looks like that idea won't fly. Note that we can (and should) version the MK API package independently on the OSGi package export level. There's no need for the API to reside in a separate component for that. i am not convinced. i would still prefer a separate component. OK, so let's have a separate oak-mk component for the MK API. More generally though and as discussed a bit already earlier, I'm still not completely convinced that we'd need (or want) different implementations of the *entire* MK interface. The MK covers quite a bit of functionality, from basic stuff like JSON parsing and formatting to complex topics like clustering and handling of merge conflicts. Do we want each MK implementation to have their own implementations of these things, or would it make more sense for a single shared MK framework to have internal extension points by which it can be deployed in various different storage and clustering configurations? With that concept, the oak-mk component would contain not just the MK API, but also the default implementation and a set of extension interfaces by which different storage, clustering and other parts can be plugged in depending on the deployment. BR, Jukka Zitting
Re: On setting component boundaries in Oak
Hi, Alternatively, if we intend to have JCR as the only API through which Oak repositories are accessed, then I completely agree with Thomas that there's not much point in putting the JCR binding to a separate component. There is probably some misunderstanding... I didn't mean that the JCR binding is the only way to access the repository. What I didn't agree was that we need to create multiple projects/components/jar files right now, before we even really started development. And I'm not convinced we need multiple projects/components/jar files even if we do support other bindings. Regards, Thomas
Re: On setting component boundaries in Oak
Hi, therefore i would strongly suggest to separate jcr-transient space from an SPI layer from the very beginning. Yes, I think we all agree on about the separation. What we not seem to agree is if separate packages is a good enough separation for now, or if it needs to be separate projects right from the start. I think multiple packages is good enough separation for now, while it doesn't slow us down as splitting things into multiple projects would. Please note there will be quite a lot of common code used in both the transient space and the SPI. Do you like us to create a separate project for that, also right from the start? Would you also create another project for the common code used by the MicroKernel, the SPI, and the transient space? Regards, Thomas
Re: On setting component boundaries in Oak
On Fri, Mar 9, 2012 at 2:15 PM, Angela Schreiber anch...@adobe.com 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. 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. +1, i absolutely agree with angela. cheers stefan 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. 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? my answer was that everything that needs validation for overall consistency and JCR compliance goes to the core (spi impl). 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. i agree 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. 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. regards angela BR, Jukka Zitting
Re: On setting component boundaries in Oak
hi thomas therefore i would strongly suggest to separate jcr-transient space from an SPI layer from the very beginning. Yes, I think we all agree on about the separation. ok... that wasn't totally clear to me. I think multiple packages is good enough separation for now, while it doesn't slow us down as splitting things into multiple projects would. why does splitting into components slows down anyone? you are claiming that this was the case but i can't follow your reasoning and would like to understand what exactly would slow you down. for me many components never used to be a problem. not even multiple jcr implementations... but maybe that's only me. i know by heart what is where and why. Please note there will be quite a lot of common code used in both the transient space and the SPI. for example? json utilities? txt-utilities? or what are you referring to. and yes, for that i would create a commons component or try to use the current jackrabbit-jcr-commons as an initial solution. Do you like us to create a separate project for that, also right from the start? Would you also create another project for the common code used by the MicroKernel, the SPI, and the transient space? see above. and yes, i would do that. rather than copy around code. kind regards angela Regards, Thomas
Re: On setting component boundaries in Oak
Hi, Why do we need an SPI? My understanding is: so that non-Java clients such as PHP can access Oak/Jackrabbit. Plus, in case of Java, for remoting. I don't think non-Java clients will want to use JNI, so the remoting aspect is very important in my view (not necessarily urgent, but important). That would mean batch operations need to be supported. Similar to the MicroKernel API, but with a lot more functionality. Regards, Thomas
