You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directmemory.apache.org by Jeff MAURY <je...@jeffmaury.com> on 2012/06/29 11:35:02 UTC
Remove Serializer for server text/plain exchange type
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 ?
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
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 ?
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
Re: Remove Serializer for server text/plain exchange type
Posted by Jeff MAURY <je...@jeffmaury.com>.
On Sun, Jul 1, 2012 at 10:00 AM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/6/29 Jeff MAURY <je...@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
Re: Remove Serializer for server text/plain exchange type
Posted by Olivier Lamy <ol...@apache.org>.
2012/6/29 Jeff MAURY <je...@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 ?
>
> 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