[infinispan-dev] ISPN-872 - MIME type for pure binary forms?

[Michal Linhard]

On 01/13/2011 09:44 AM, Galder Zamarreño wrote:
> Hi all,
>
> Re: https://issues.jboss.org/browse/ISPN-872
>
> As stated in my last comment, it appears to me that Infinispan's REST server is not distinguishing between a byte array that comes from a Java client that serialized an object, and a pure byte[] that is not necessarily a serialized form of a Java object.
>
> The test added by Michal might not make sense to a lot of you (http://goo.gl/8qfnw - testByteArrayStorage), but the underlying issue is still present.
>
> Looking back at past tests, IntegrationTest.testSerializedObjects is not correct. The byte array passed is not "application/x-java-serialized-object". In fact, the server tries to deserialize it and fails, which leads to the byte[] being stored as is, but still under the "application/x-java-serialized-object" banner.
>
> My question is, what should be the type to use for pure byte arrays? Should it be "application/octet-stream" ? Any other suggestions?
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Since we're discussing this, I've been wondering (since ISPN-714), why 
do we treat MIME "application/x-java-serialized-object" specially in the 
first place ?

Why does REST server try to deserialize the bytes once it discovers they 
are "application/x-java-serialized-object" ?
Is there any special argument supporting this behaviour ? I could 
imagine some, if we wanted to share data between server modules, but so 
far this is not desirable.
Is it more space-optimal to store it this way? But then what about 
time-optimality ?

I know REST interface is not directed primarily towards java clients, 
but still I guess
"application/x-java-serialized-object" can be quite popular MIME choice, 
and since REST server does serialization and deserializaition for each 
such request,
this might even become a performance issue. (if we ignore possibility to 
use HotRod, which is obviously more suitable for java clients)

I guess with HotRod and Memcached server module no such deserialization 
takes place ... only the client knows the meaning of the bytes it feeds 
the cache.

Michal.

-- 
Michal Linhard
Quality Assurance Engineer

Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363