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 Tue, 13 Mar 2012 08:32:47 GMT
hi marcel

>>> 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.
> actually, I'm not yet convinced ;)

just because we never had time to create a native SPI implementation?
the current spi2x implementations all suffer from the having
JCR on the 'server' side again... it was never the intention
to be limited to that... instead it was always clear that the SPI
layer is intended to separate the session level (transient space)
from the workspace layer that also had to take care about
the validation and consistency.

> using the JCR API also has major advantages because we can
> reuse existing remoting as is. jcr-server exposes the JCR
> API over webdav, spi2dav exposes it again as SPI if needed
> and you can even stack jcr2spi on top of it again if you
> want JCR remoting over webdav.
> doesn't a new Oak SPI mean we have to re-implement
> all these modules again?

jcr2spi needs major refactoring anyway.
spi needs adjustments to fit our needs

and dav remoting on the spi layer could be much better
if we didn't have to convert spi to jcr again.

> I'd suggest non-java clients use the following stack:

> non-java-client<->  jcr-server<->  jcr2mk<->  mk

not really. as far as i know it was
jcr-non-java -> spi -> mk


> Regards
>   Marcel

View raw message