incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <>
Subject Re: Remove Serializer for server text/plain exchange type
Date Sun, 01 Jul 2012 08:00:09 GMT
2012/6/29 Jeff MAURY <>:
> 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 ?

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

Olivier Lamy
Talend: |

View raw message