[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Manik Surtani updated ISPN-508: ------------------------------- Priority: Critical (was: Major) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno commented on ISPN-508: --------------------------------------- Some notes: Protobuf requires a model to be defined in advance and classes to be generated, so this means that from a user perspective, whatever key/value that is passed to the Hot Rod client, it'd need to be casted to MessageLite to be able to call toByteArray method (http://code.google.com/apis/protocolbuffers/docs/reference/java/com/googl...). In a way this reminds me a bit of what users had to with their user classes to put them into PojoCache where they had to pre-compile and aspectize their classes so that they could be woven. This could potentially generate a lot of questions in forums based on my experience of users having to do these type of things themselves. Another thing that worries me about Protobufs would be how to do the reading part. According to http://code.google.com/apis/protocolbuffers/docs/javatutorial.html, the reading requires calling parseFrom(byte[]) static method on the object class. However, this parseFrom does not appear to belong to any class. The only thing I've found is http://code.google.com/apis/protocolbuffers/docs/reference/java/com/googl... which can parseFrom a arbitrary type given the descriptor. How would the unmarshaller know either the descriptor or class to use to return? I'll look at Avro next... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno commented on ISPN-508: --------------------------------------- I've had a brief look at Apache Avro and here's what I've found out so far: In terms of documentation, it's way behind protobufs. The only examples available are the quickstart which covers just one case (which btw is the same one as protobug where it generates classes based on a given JSON schema!) and then the Avro testsuite. The key thing in Avro is that is supposed to be consumed as an RPC library where you have the objects you want to write to wire and the remote methods you actually want to call where you marshall that data. So, all examples are geared towards that, rather than showing how to convert an object back/fwd a byte[]. For example, examples focus on creating a ServerSocket, Socket and how it creates a proxy for the object containing the RPC method and how you pass your object to it. One of the most appealing things about Avro was dynamic typing where Avro does not require code to be generated as data is always accompanied by the schema. The schema is gonna have to come from somewhere and this means that either: you're gonna have to come up with a schema and generate your java code (same thing as protobufs does. In avro terms, they call this specific API) or let the reflection layer in avro do this which I'm not terribly excited about, particularly after reading the note in http://avro.apache.org/docs/current/api/java/org/apache/avro/reflect/pack... where it says that reflection should only be used as a bridge until you've moved to used specific API where schemas are known at compilation time. The final way to serialize data is what they call generic where an object to serialize is constructed from a JSON schema known at runtime. We're not interested in this since we get the pojo given to us by the user. It's worth noting that reflection based marshalling is not covered in the benchmarks shown in http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking. It only covers specific (ala protobuf) and generic APIs. I'm gonna try to build small prototypes with both to get a better idea of how all this would be coded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-508: ---------------------------------- Attachment: thrift-sandbox.zip I had a look at Thrift now and it has the same problem as protobufs. In fact, in this case you need build a new instance of the target type when reading, so you need the type when reading once again. So any potential solution would require clients to give us the byte[] directly and for them to serialize/deserialize. Please find attached some code showing what users would most likely need to code, in particular focus on GenericMarshallingThrift. The advantage of Thrift over Protobufs though is the fact that it has many more generators, i.e. C++, C#, Erlang, Haskell, Java, Objective C/Cocoa, OCaml, Perl, PHP, Python, Ruby, and Squeak. This is compared to Java, C++ and Python that Protobufs only supports. The disadvantage of Thrift is that it looks less matured than Protobufs. I had to use a nightly build to build the thrift command needed to generate the classes. The latest available release (0.2.0 (released on 2009-12-11)) could not be built in my machine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno commented on ISPN-508: --------------------------------------- Check MessagePack as well: http://msgpack.org/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-508: ---------------------------------- JBoss Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2010-July/005959.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-508: ---------------------------------- Attachment: msgpack-sandbox.zip Here's a similar attempt using MessagePack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-508: ---------------------------------- Fix Version/s: 5.0.0.ALPHA1 (was: 5.0.0.BETA1) Actually fixed for alpha1 already -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira