[infinispan-dev] REST server, dealing with Serializable

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] REST server, dealing with Serializable

Sebastian Laskawiec
Hey Guys!

I'm currently reworking REST interface and I'm scratching my head looking how we deal with Serializable [1][2]. 

The scenario assumes that server knows that cache stores a Serializable instance and moreover, it knows how to deserialize it (and convert it to XML/JSON, but that's the trivial part). I might be wrong, but I think both assumptions are questionable if not wrong. At first, how to distinguish a serialized instance of a class the server received [3] from a standard byte array? I can imagine someone using "Content-type: application/x-java-serialized-object" but it's very error prone. It also leads to the question number two - how the server will know that type of instance it is? This knowledge is essential for deserialization.

I think the serialization/deserialization should be really done on the client side (but as I mentioned before, maybe I don't see some important use cases). I would like to remove it from refactored REST server.

What do you think?

Thanks,
Sebastian

--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] REST server, dealing with Serializable

Gustavo Fernandes-2
With the upcoming transcoding support [1], each cache will have a MimeType configured for key and value. This will allow, for example, to
differentiate from a byte[] that is a JPEG image, a gzipped text, some UTF-8 bytes, Jboss marshalled object, protostream marshalled message and so on.
At runtime, it'll be possible to read and write to/from the cache specifying a different MimeType and the appropriate transcoder will convert the values on demand.

Gustavo

[1] https://issues.jboss.org/browse/ISPN-7417

On Mon, Apr 24, 2017 at 9:27 AM, Sebastian Laskawiec <[hidden email]> wrote:
Hey Guys!

I'm currently reworking REST interface and I'm scratching my head looking how we deal with Serializable [1][2]. 

The scenario assumes that server knows that cache stores a Serializable instance and moreover, it knows how to deserialize it (and convert it to XML/JSON, but that's the trivial part). I might be wrong, but I think both assumptions are questionable if not wrong. At first, how to distinguish a serialized instance of a class the server received [3] from a standard byte array? I can imagine someone using "Content-type: application/x-java-serialized-object" but it's very error prone. It also leads to the question number two - how the server will know that type of instance it is? This knowledge is essential for deserialization.

I think the serialization/deserialization should be really done on the client side (but as I mentioned before, maybe I don't see some important use cases). I would like to remove it from refactored REST server.

What do you think?

Thanks,
Sebastian

--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] REST server, dealing with Serializable

Sanne Grinovero-3
In reply to this post by Sebastian Laskawiec


On 24 April 2017 at 09:27, Sebastian Laskawiec <[hidden email]> wrote:
Hey Guys!

I'm currently reworking REST interface and I'm scratching my head looking how we deal with Serializable [1][2]. 

The scenario assumes that server knows that cache stores a Serializable instance and moreover, it knows how to deserialize it (and convert it to XML/JSON, but that's the trivial part). I might be wrong, but I think both assumptions are questionable if not wrong. At first, how to distinguish a serialized instance of a class the server received [3] from a standard byte array? I can imagine someone using "Content-type: application/x-java-serialized-object" but it's very error prone. It also leads to the question number two - how the server will know that type of instance it is? This knowledge is essential for deserialization.

I think the serialization/deserialization should be really done on the client side (but as I mentioned before, maybe I don't see some important use cases). I would like to remove it from refactored REST server.

​To answer this specific question: the server needs to be able to serialize / deserialize the objects for many reasons.
Among these we have:
 - compatibility mode
 - "transcoding" among different clients expecting different types
 - indexless queries (read and compare specific fields)
 - indexed queries (index specific fields)
 - firing events​ (on anything more useful else than "blob was changed")
 - avoid losing the data when encoding schemes are updated (e.g. an Infinispan update which includes improvements / fixes on the serialized representation )

It's probably not an exhaustive list as I didn't follow this subject closely, but I guess there are enough reasons there to clarify why just encoding/decoding at the client side is not good enough.

Thanks,
Sanne


 
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] REST server, dealing with Serializable

Sebastian Laskawiec
Ok, understood. The bottom line is - yes, we need to support Serializable.

Thanks for clarification!
Sebastian

On Mon, Apr 24, 2017 at 11:38 AM Sanne Grinovero <[hidden email]> wrote:
On 24 April 2017 at 09:27, Sebastian Laskawiec <[hidden email]> wrote:
Hey Guys!

I'm currently reworking REST interface and I'm scratching my head looking how we deal with Serializable [1][2]. 

The scenario assumes that server knows that cache stores a Serializable instance and moreover, it knows how to deserialize it (and convert it to XML/JSON, but that's the trivial part). I might be wrong, but I think both assumptions are questionable if not wrong. At first, how to distinguish a serialized instance of a class the server received [3] from a standard byte array? I can imagine someone using "Content-type: application/x-java-serialized-object" but it's very error prone. It also leads to the question number two - how the server will know that type of instance it is? This knowledge is essential for deserialization.

I think the serialization/deserialization should be really done on the client side (but as I mentioned before, maybe I don't see some important use cases). I would like to remove it from refactored REST server.

​To answer this specific question: the server needs to be able to serialize / deserialize the objects for many reasons.
Among these we have:
 - compatibility mode
 - "transcoding" among different clients expecting different types
 - indexless queries (read and compare specific fields)
 - indexed queries (index specific fields)
 - firing events​ (on anything more useful else than "blob was changed")
 - avoid losing the data when encoding schemes are updated (e.g. an Infinispan update which includes improvements / fixes on the serialized representation )

It's probably not an exhaustive list as I didn't follow this subject closely, but I guess there are enough reasons there to clarify why just encoding/decoding at the client side is not good enough.

Thanks,
Sanne


 
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev