incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff MAURY <jeffma...@jeffmaury.com>
Subject Re: Remove Serializer for server text/plain exchange type
Date Mon, 02 Jul 2012 22:18:47 GMT
On Sun, Jul 1, 2012 at 10:00 AM, Olivier Lamy <olamy@apache.org> wrote:

> 2012/6/29 Jeff MAURY <jeffmaury@jeffmaury.com>:
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message