Re: [infinispan-dev] HotRodMarshaller interface
At least for 1 and 2, I think it'd be good to keep in mind what Phillipe suggested in
http://lists.jboss.org/pipermail/infinispan-dev/2010-February/005195.html
Basically, currently org.infinispan.marshall.Marshaller does too many things. At a global
level it does:
- marshalling to/from streams
- marshalling to/from byte[]
Now, your suggestion to have a BasicMarshaller is the same that Phillipe did to have a
ByteArrayMarshaller. IOW, have an interface for simply marshalling to/from byte[].
At least for 4.1, we could create the [Basic/ByteArray]Marshaller interface and have
Marshaller inherit from it. For 5.0 we might want to have the stream marshaller as well so
that Phillipe can find an easier way to add compression.
I can work on this myself since I know the marshaller API pretty well.
Wrt 3, I'm not so sure of the benefit of separating between marshalling a key (small)
or value (large). At the marshaller level used to send stuff accross the cluster, we
always use the same initial size, 128, and I don't recall seeing hot spot or anything
around byte array resizing.
On Jul 8, 2010, at 3:57 PM, Manik Surtani wrote:
Guys,
I just created ISPN-532 (HotRodMarshaller needs cleaning up) targeted for Radegast CR2
and Final. I know it is late in the day to be making API changes in an interface, but I
would much rather this is done right prior to being baked into Final and hence eternity.
:)
http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src...
So I have 3 issues to address with this interface.
1. Methods on the interface
The purpose of this is simple: the 2 methods, readObject() and marshallObject() are meant
to perform diametrically opposed tasks (byte[] -> object in one case, object ->
byte[] in the other) but the names are far from that.
I propose either of the following:
1) readObject() and writeObject()
2) Simply, read() and write()
3) Or if we want to follow org.infinispan.marshall.Marshaller conventions,
objectFromByteBuffer(), objectToByteBuffer()
My preference would be (3).
2. Interface name and package
Further, any reason why we call this HotRodMarshaller? Isn't it just a marshaller
that serializes arbitrary objects <--> byte[] and should contain no HotRod-specific
logic? I can see why we did not use the org.infinispan.marshall.Marshaller interface for
this (too complex?) but perhaps we could create a org.infinispan.marshall.BasicMarshaller
which just contains objectFromByteBuffer() and objectToByteBuffer(), and Marshaller can
extend BasicMarshaller for Infinispan's internals and HotRod clients can directly
implement BasicMarshaller?
This would allow people who write custom marshallers to reuse them for both the HotRod
client as well as for Infinispan's internal marshalling.
3. isKeyHint parameter on marshallObject()
What is this for? And surely there is a more elegant/generic way to achieve this?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache