jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Semantics of MicroKernel.getNodes()
Date Thu, 15 Mar 2012 08:44:21 GMT
On Wed, Mar 14, 2012 at 4:47 PM, Michael Dürig <mduerig@apache.org> wrote:
>
>
> On 14.3.12 14:54, Julian Reschke 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).
>
>
> Couldn't we use the filter parameter for such cases. AFAIK the parameter is
> currently in the API only and its semantics is not defined yet. So if we
> come up with the right semantics for it, wouldn't that work?

i added the filter parameter for specifying the properties to be
included in the json response but the format/syntax is still TBD.

IMO there should be an implicit default filter (e.g all user-defined properties
+  the system-defined ':childNodeCount' property).

the ':hash' property should only be included on demand, i.e. when it is
specified in the filter.

cheers
stefan


>
>
>> 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).
>
>
> Right. It was decided very early in the process to make the API string based
> in order to be language agnostic (i.e. leave the option for a C
> implementation). However we should really re-evaluate this requirement and
> its consequences taking into account the current situation.
>
> Michael
>
>>
>>
>> Best regards, Julian

Mime
View raw message