jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: MicroKernel API vs. protocol
Date Mon, 19 Mar 2012 23:18:35 GMT
On 2012-03-19 23:34, Jukka Zitting wrote:
> Hi,
> On Mon, Mar 19, 2012 at 9:31 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> There's also a concern that isn't directly about strings vs objects but
>> about "flat or not". Forcing getNodes to return things as a hierarchy, when
>> it also could be a list of objects, decorated with a path, will make it
>> harder than it needs to be to process efficiently.
> Do you have a particular use case or access pattern in mind?

Streaming the result of a huge collection. If you have a flat list of 
things keyed by the path, it's very easy to consume because you don't 
need to hold state about the nesting level.

>> I believe that in order to remote things efficiently, we still need to be
>> able to optimize the number of requests. This means asking for a set of
>> NodeStates, for a hierarchy, and also filtering the result set (or selecting
>> specific parts of the hierarchy).
> Note that one remote request doesn't necessarily need to map to just a
> single Java API call. Filtering a list of results can easily be done
> on top of the NodeState interface. Doing it below the interface is
> only useful in case we can expect a performance or other benefit from
> doing so. Do we?

If you make it hard to optimize the network layer, it, well, will be 
hard. We see this today in WebDAV-based remoting in SPI2DAV.

Also, selecting a subset of the information to be returned is not only 
about payload size but also about avoiding to compute it.

>> I probably sound like a broken record but there's a reason why WebDAV's
>> PROPFIND/multistatus looks the way it does.
> Right. But as mentioned earlier, the constraints for WebDAV as a
> network protocol are quite different from those of a Java API that can
> leverage stuff like lazy loading. A method like the mentioned
> getRootNodeState(String revision) is perfectly fine for a Java API,
> whereas the equivalent WebDAV request would end up serializing the
> entire content tree.

I think we need an API that allows the caller to be very specific about 
what information is needed. If the API doesn't allow expressing this, 
we'll always fetch more information than we need at once, or end up 
doing many network requests instead of a single one.

Best regards, Julian

View raw message