On Thu, Jun 28, 2012 at 11:16 AM, Jukka Zitting <[email protected]> wrote: > 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.
"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, ...). cheers stefan > > BR, > > Jukka Zitting
