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 Wed, 14 Mar 2012 15:54:24 GMT
On 2012-03-14 16:47, Michael Dürig 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?

It probably will, and we should keep this use case in mind when we 
define it.

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

String-based doesn't necessarily imply it needs to use Java String 
objects (and yes, Thomas, I saw your comment and will have a look at that).

In general, if Java talks to Java of course it's a waste of time to 
serialize things into a String that need to be parsed again next. The 
JSON data model may be the right thing, and using application/json on 
the *wire* may make a lot of sense, but that doesn't necessarily mean it 
needs to be the only thing a Java API to the MicroKernel accepts...

Best regards, Julian

View raw message