jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [j3] Repository MicroKernel API draft
Date Mon, 20 Jun 2011 10:50:42 GMT

>>why JSON strings?
>> - easy portability
>> - remoting-friendly
>> - leads to very compact API
>> - JSON parsing/generating overhead is IMO minimal
>>    and probably more effecient than creating (and collecting) tons of
>>    small java objects on the heap
>I doubt this. In fact I think the situation with the small Java objects
>is even worse in the face of a JSON based API: typically a
>(de)serialization layer will create an additional set of intermediate
>objects which have to be consumed/translated into the domain objects of
>the respective implementation.

Only if the implementation needs to do anything with the values (except
for storing and retrieving). The MicroKernel doesn't care about most of
the values - they are just stored "as is". The only object that is
currently created for each value is a string that *shares the content*
with the Json diff string (which is part of the API). So the in-memory
overhead is low (on the MicroKernel side).

The MicroKernel *client* on the other hand anyway needs a more complex
object model. It doesn't make sense if the MicroKernel knows anything
about that.

I'm not saying the Json based API is the 'fastest possible' or the one
that uses the 'least' memory. But I also don't think the situation is very


View raw message