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
