On 9 Jul 2013, at 14:20, Emmanuel Bernard <[email protected]> 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 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
