jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject To String or not To String (was: Semantics of MicroKernel.getNodes())
Date Thu, 15 Mar 2012 09:24:17 GMT

Am 15.03.2012 um 09:49 schrieb Stefan Guggisberg:

> On Wed, Mar 14, 2012 at 2:54 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 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).
> good point. how about returning a character stream (Reader/Readable)
> instead of a string?

I would like to start discussing whether it really makes sense to have String as the argument
types of the methods and saying the String values are actually seriaized JSON data.

Almost all interaction will involve serialization and deserialization, which costs resources
(time, CPU, memory).

It has been said, that this is done to allow for non-Java implementations. I think this argument
is not really valid. All programming languages in use today allow for structured data (even
plain old C). So there is no need for a String API.

It has been said, that for writing to the storage or for remoting a String is more helpful.
I hold that the use of the data is an implementation detail. And if this detail would be important
enough to make it into the API, it would really have to be byte[].

It has been said, there are wrappers on top of the API to provide data structure oriented
API. It also has been said, that if we have such wrappers, something sounds wrong. I tend
to agree with this.

So, I think that we should really replace the String-type arguments and results said to be
serialized data structures to real data structures we can document and fill with semantics.

View raw message