Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.23 as permitted sender)
Message-ID: <4F684F15.8010206@gmx.de>
Date: Tue, 20 Mar 2012 10:34:13 +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: Thomas Mueller <mueller@adobe.com>,
 Jukka Zitting <jukka.zitting@gmail.com>
Subject: Re: MicroKernel API vs. protocol
References: <CB8DE7C3.28056%mueller@adobe.com>
In-Reply-To: <CB8DE7C3.28056%mueller@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2012-03-20 09:07, Thomas Mueller wrote:
> ...
>> 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.
>
> So far I didn't think this is a problem, but I'm not sure if I understand
> what you mean exactly. Could you give a example how an alternative
> representation would look like?
> ...

Right now we return a tree, such as:

"a" : { ":childCount" : 1, "title" : "foo",
	"b" : { ":childCount" : 0, "title" : "bar" }
}

The idea would be to return an array of leaf nodes, keyed by their 
identifiers.

Such as

[ "a" : { ":childCount" : 1, "title" : "foo" } ],
[ "a/b" : { ":childCount" : 0, "title" : "bar" } ]

etc...

The benefit is that it's slightly easier to process in a streaming way, 
because it's just an iterator over node infos, instead of a tree.

Best regards, Julian