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: MicroKernel API vs. protocol
Date Mon, 19 Mar 2012 22:34:42 GMT
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?

> 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?

> 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.

BR,

Jukka Zitting

Mime
View raw message