Hi,

On Thu, Jun 28, 2012 at 9:07 AM, Felix Meschberger <[email protected]> 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.

BR,

Jukka Zitting

Reply via email to