To String or not To String (was: Semantics of MicroKernel.getNodes())

[Felix Meschberger <fm...@adobe.com>]

Hi,

Am 15.03.2012 um 09:49 schrieb Stefan Guggisberg:

> On Wed, Mar 14, 2012 at 2:54 PM, Julian Reschke <ju...@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.

Regards
Felix