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: Semantics of MicroKernel.getNodes()
Date Thu, 15 Mar 2012 12:16:22 GMT
On 2012-03-15 09:49, Stefan Guggisberg wrote:
> On Wed, Mar 14, 2012 at 2:54 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> Hi there,
>> I'm looking at MicroKernel.getNodes(), and I believe the semantics might
>> perform non-optimal unless we get the property filtering right.
>> A typical use case always is browsing a repository using a tree view.
>> A tree view usually needs, given a node N:
>> - all or a subset of all properties of node N
>> - the set of child node names, and for each of these child nodes, a
>> predefined set of properties that will allow the caller to decorate the node
>> properly -- such as whether it's a container, and maybe the type).
>> Another problem is the String-fits-all return type; it would make it
>> impossible to implement streaming of the result to the client; which will
>> make the behavior for large collections non-optimal (the caller needs to
>> wait for the complete JSON string to be ready before it can start forwarding
>> information up the stack).
> good point. how about returning a character stream (Reader/Readable)
> instead of a string?
> ...

I think it would help.

A more general issue is the reliance on a JSON-type tree; this looks 
simple, but it means that returning information about lots of nested 
child nodes makes it harder to process the result, unless you're willing 
to wait for the end.

I always wondered why WebDAV multistatus messages contain a flat list of 
response elements (with the path being part of the response), instead of 
nesting. I believe I now know why; it makes streaming *much* easier (and 
before somebody claims that's academic; I have implemented that in a 
server in the past).

Best regards, Julian

View raw message