Hi, >>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 bad. Regards, Thomas
