jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: On setting component boundaries in Oak
Date Mon, 12 Mar 2012 13:51:57 GMT
Hi,

On Mon, Mar 12, 2012 at 2:28 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> 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.

Regardless of where (or if) we draw internal component boundaries, we
still have the option of using all our existing JCR-based client
components, so we're not really taking anything away.

The question here is mostly about whether we want to *also* offer a
lower-level API that provides direct access to some features that
can't be (easily) expressed through JCR.

For example a lower-level WebDAV binding could potentially include
strong ETags for improved caching support based on the MVCC model in
case we make such information available through the potential Oak API.
Or a backup client as discussed could leverage potential better bulk
read functionality to speed things up.

> doesn't a new Oak SPI mean we have to re-implement
> all these modules again?

It doesn't mean that we *have to*, just that we can if we want to.

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.

BR,

Jukka Zitting

Mime
View raw message