On 2012-03-19 23:34, Jukka Zitting wrote:
Hi,
On Mon, Mar 19, 2012 at 9:31 PM, Julian Reschke<[email protected]> 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
