[infinispan-dev] protobuf as a marshalling format for infinispan remote-query

[Emmanuel Bernard]

On Wed 2013-07-10 16:18, Mircea Markus wrote:
> 
> On 9 Jul 2013, at 14:20, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> >>> 
> >>> Ah it's quite sad protostuff does not live up to the expectation :(
> >>> 
> >>> Compared to the google libs, streamlike is definitely a nice approach but I feel a bit sad to have to use marshallers and the read/write pattern. Having maintained compatibility of Java serializable object, such approach gives me the creep. How would your read code end up after a couple of evolutions, with ifs and other condition branches?
> >> 
> >> Compared with serializable objects, ProtoStream offers runtime validation based on the proto file which should help maintenance.   
> >> 
> >>> There is no example in your tests that I could find. 
> >>> 
> >>> Do you think either the protostuff approach or even protostuff itself is salvageable ?
> >> 
> >> There were prototypes written with conversion between domain objects and protoXyz generated classes and the code quite ugly.  
> > 
> > What is ProtoXyz? Anyways, I thought Protostuff was doing just that: runtime binding of a domain model. You are saying that the generated code of ProtoStuff was crap?
> 
> protoXyz = protostuff || protbuf
> The generated code +  writing adapters to transform it to domain model classes was ugly and much harder to read/write then the ProtoStream(TM) approach we suggest. 
> E.g. see the decode/encode methods here, that convert between protoc generated classes and custom domain objects: http://goo.gl/d9FVo compared to the one based on ProtoStream: http://goo.gl/TKGeu

Sorry, I have a hard time to follow. The runtime schema as proposed by
protostuff is only involving the domain model and some annotations
https://code.google.com/p/protostuff/wiki/ProtostuffRuntime

The custom domain object prototype seems to use the protoc generated
builder which I agree are PITA for a user.

Let me know if I summarize incorrectly but:

1. The stream approach uses a Java serialization style code (with some
runtime verification from what you said). Some read / write impl is
mandatory from the get go to transfer an object

2. The Google protoc builder stuff requires the user to use the builder
API to get or transform its domain model

3. The runtime model from Protostuff uses annotations to fine tune the
schema evolution (forward / backward compatibility)

BTW if there were any discussion on this mailing list or elsewhere logged,
feel free to point them to me instead of duplicating, I might have missed them.

Emmanuel