On Sun, Jul 1, 2012 at 10:00 AM, Olivier Lamy <[email protected]> wrote:
> 2012/6/29 Jeff MAURY <[email protected]>: > > Hello, > > > > as we reached a first milestone for DirectMemory, I would like to share > my > > thoughts about one issue on the server. > > As of today, the server supports three exchange types: JSON, Java > > serialized object and text/plain. > > The text plain exchange type exchange a string between the client and the > > server, and the format of the string is up to the client: it can be a > > string object (in that case, the content is sent) or it can be a JSON > > representation of a more complex object. > > I have seen several drawbacks in the current implementation: > > 1) the string is sent as a binary entity and there may be encoding issues > > if the client and the server don't share the same default encoding > schema: > > why not send as a string entity and use the charset HTTP Content-Type > > parameter ? > > +1 > > > 2) On the server side, the string is stored in the cache as a byte array, > > and the serialization is performed using the Directmemory serializer > > framework which can be controlled by the client: it causes a coupling > > between the client and the server which is not desirable: why don't we > > store the content as a string or if we want to keep byte array, use the > > standard JDK String serialization (I would propose UTF-8 as the charset). > > In that case, we could get rid of the Serializer framework for this > > exchange type > > +1 > > > 3) Last point, there is no separation between the exchange types: so if > one > > client put an entry using one exchange type (let suppose text/plain) and > > another retrieve the entry with the same key using another exchange type > > (let suppose Java serialized), then the entry will be retrieved but it is > > likely the format is not correct: should be check or let the client be > > consistent ? > > Could be a "nice to have" control. But we will need a new data > structure to store this exchange type ? > Yes unless we use the exchange type as a prefix for the key so segmentation is performed using the key: cachekey = exchange_type ':' user_key Jeff > > > > > Regards > > Jeff > > > > > > -- > > Jeff MAURY > > > > > > "Legacy code" often differs from its suggested alternative by actually > > working and scaling. > > - Bjarne Stroustrup > > > > http://www.jeffmaury.com > > http://riadiscuss.jeffmaury.com > > http://www.twitter.com/jeffmaury > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
