jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Native HTTP bindings for Oak
Date Thu, 28 Jun 2012 09:48:36 GMT
On Thu, Jun 28, 2012 at 11:16 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Thu, Jun 28, 2012 at 9:07 AM, Felix Meschberger <fmeschbe@adobe.com> wrote:
>> How about remotely located oak-jcr installs ?
>> As in: oak-jcr on box X talking to oak-core on box Y. This should probably be able
to leverage this new  binding.
>> Or do you envision some different Oak API remoting ?
> API remoting isn't my primary goal behind the HTTP binding, though it
> might also come in handy for that purpose.
> However, as Stefan pointed out (server roundtrips for each addNode
> call), the HTTP binding as such (i.e. as a one-to-one mapping for Oak
> API calls) probably isn't at the correct level of granularity for
> remote JCR access. A remote JCR client probably in any case needs a
> (potentially partial) client-side transient space like the one we have
> in jcr2spi if it wants to avoid the kind of massive performance hit
> you get with the JCR-RMI remoting layer. I'm not sure whether solving
> that issue on to of the Oak HTTP binding is worth the effort when we
> already have the SPI-based JCR remoting mechanism that works
> reasonably well.

"reasonably well" is IMO not good enough ;) the SPI-based JCR remoting
would need to go to several layers (jcr2spi, spi2jcr, oak-jcr, oak-core,...).
that's hardly efficient. whereas the obvious remoting layer (oak api) would
allow a much leaner layering (oak-jcr, remoted oak-core, ...).


> BR,
> Jukka Zitting

View raw message