Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.22 as permitted sender)
Message-ID: <4F60BF30.6040001@gmx.de>
Date: Wed, 14 Mar 2012 16:54:24 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: oak-dev@jackrabbit.apache.org
CC: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
Subject: Re: Semantics of MicroKernel.getNodes()
References: <4F60A2FB.8010203@gmx.de> <4F60BD76.3020800@apache.org>
In-Reply-To: <4F60BD76.3020800@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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