hi, I like the idea of a micro kernel. However, I don't think that the SPI is a good starting point. it contains the full feature set of JCR. I guess the current interface that best matches the micro-kernel idea is the PersistenceManager interface. It strictly deals with persistence, which is something that the micro-kernel implementation should do as well, IIUC.
the gaps that I see are: - tree and referential integrity awareness, it must be impossible to create inconsistent data using the micro-kernel API (currently a misbehaving client of the PersistenceManager API can currupt data) - may behave eventual consistent. what's the effect on the micro-kernel API? - support read-only multi-versioning. how are versions identified? transaction id, timestamp? - low-level copy/clone (are there other workspace operations that would benefit from micro-kernel API support?) - long running transaction support? I'm not sure about this one. the use case here is writing transient modification directly to the micro-kernel. I think Jukka thought about this already when he prototyped his Next Gen Persistence a while ago. I think this would come in very handy when we want to support large transactions. see other thread. from an implementation perspective, we'd need to use optimistic concurrency control (like we do currently) and merge overlapping changes whenever possible. regards marcel On Thu, Feb 18, 2010 at 13:13, Alexander Klimetschek <[email protected]> wrote: >> On Wed, Feb 17, 2010 at 4:48 PM, Jukka Zitting <[email protected]> >> wrote: >>> Assuming we have a unified persistence layer (see the other thread), >>> it should be possible to implement a relatively simple repository >>> "microkernel" that implements just enough functionality for higher >>> level components like search, versioning, node types, observation, >>> etc. to be implemented on top of it. > > +1 > > On Thu, Feb 18, 2010 at 11:50, Stefan Guggisberg > <[email protected]> wrote: >> absolutely. the SPI would IMO be an ideal starting point for such a >> microkernel api. we might need to review/strip it though. > > +1 > > I think we should start with a scalable persistence layer (as > discussed in the other threads) and from there find the simplest API > needed for it, and then merge it with the existing SPI. An important > goal for that microkernel API would be that you can implement it > within one day (functionally, not necessarily fast), as compared with > the full JCR API, that requires many things like node types, > observation, shareable nodes, versioning etc. > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
