jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [jr3] Repository microkernel
Date Fri, 19 Feb 2010 09:07:30 GMT

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.


On Thu, Feb 18, 2010 at 13:13, Alexander Klimetschek <aklimets@day.com> wrote:
>> On Wed, Feb 17, 2010 at 4:48 PM, Jukka Zitting <jukka.zitting@gmail.com> 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
> <stefan.guggisberg@gmail.com> 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
> alexander.klimetschek@day.com

View raw message