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
