Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
I fully second that opinion. We rely a lot on being able to set explicit defaults that are not language defaults (Java 0, , false, etc). It puzzles me to even think as to why someone might want to take that feature away!!! On Wednesday, January 14, 2015 at 6:50:37 AM UTC-6, Jeremy Swigart wrote: That sounds like a poor design decision, and one easily readded without breaking anything. If a field doesn't have an explicit default, you use 0 or whatever, thereby not breaking anyone not using them, but if an explicit default is provided that is used instead. I am using that feature as well. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Protobufs to XML
Look at this library: http://code.google.com/p/protobuf-java-format/ On Jul 9, 4:40 pm, Rinku rinkuta...@gmail.com wrote: Hello, Can someone help me get the decoded data stored in a protobuf on to an xml file? How do I do that? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] protoc plugin generator using Java
I've tried to use the experimental Java support for writing the protoc plugins from http://codereview.appspot.com/912042/show Everything got compiled correctly but when I started using it, got the following error: protoc --java_out=. --plugin=protoc-gen-my --my_out=. config.proto --my_out: protoc-gen-my: Plugin output is unparseable. Redirecting the output of 'protoc-gen-my' script to a file and then trying to recreate the 'CodeGeneratorResponse' in code worked without any issues. However when using it with protoc, it refuses to parse it. :( This is the content of my 'protoc-gen-my' script: #!/bin/bash #cd `dirname $0` #java -Xdebug - Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar protobuf-java-codegen-0.1.jar #java -jar protobuf-java-codegen-0.1.jar 1 data.pb java -jar protobuf-java-codegen-0.1.jar Any idea what I could be doing wrong? Thanks, Alex -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Existing domain model
You might want to check out http://code.google.com/p/protostuff/ On Jul 3, 7:30 am, Pradeep Thomas ptprad...@gmail.com wrote: We have an existing object model in java with hibernate annotations for persistence. For client-server communication what are the pros of cons of using protocol buffers, because we do not not want to modify the existing object model or generate it again. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: using compression on protobuf messages
On Jun 22, 3:04 pm, Evan Jones ev...@mit.edu wrote: On Jun 22, 2010, at 15:35 , sheila miguez wrote: I've got a servlet filter which wraps the HttpServletResponse. So, the servlet response's output stream, which is wrapped in a stream from the lzo library, is compressing data as it is getting written to. Ah, so the best case is probably message.writeTo(servletOutputStream) If you are writing multiple messages, you'll probably want to explicitly create a single CodedOutputStream to write all of them. If you experiment with this and find something different, I would be interested to know. Evan -- Evan Joneshttp://evanjones.ca/ Evan, thatnks for the great tip about using CodedOutputStream for the writing of protobuf into a compressible stream. When calling a .toByteArray() method and then writing it to a CompressionOutputStream, it takes 396,078,181 ns to compress 112,178 bytes. When I use .writeTo(...) and pass it a CompressionOutputStream as an input, it takes only 38,226,661 ns to compress 112,178 bytes. So its almost a 10x reduction, which is GREAT!!! Now I'm trying to figure out how I can speed up the decompression on the receiving side. What I have right now is: * Take the CompressionInputStream, convert it into a byte[] * Take the resulting byte[] and do .parseFrom(byte[]) This seems to be a faster route, then just doing .parseFrom(CompressionInputStream). 10,404 bytes of compressed payload takes 181,643,533 ns to decompress and convert into a proto message using .parseFrom(CompressionInputStream). 10,404 bytes of compressed payload takes only 155,264,303 ns, when first I create a byte[] and then pass it into .parseFrom(byte[]) on the message. Any thoughts on how this can be (if possible at all) made even faster?! :) Thanks, Alex -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: XML to Protocol Buffers converter
Jason, there is a project that contains the XML JSON marshalers for
protobuf and back which would do exactly what you want:
http://code.google.com/p/protobuf-java-format
Thanks,
Alex
On Oct 13, 3:35 pm, Jason Smith jasonfsmi...@gmail.com wrote:
I wrote a generic proto-to-xml routine (using TinyXML) that'll convert
any Message* into XML. Thanks to the reflection interface and
TextFormat, it was pretty straightforward. (if there's interest in
seeing it let me know... I'll clear it with my boss and post to this
forum).
Now I'm trying to do the reverse, and I'm having issues with repeated
fields that are themselves messages. When parsing the XML it finds a
repeated message, but I can't figure out what method to call in order
to automagically create a new object of the correct derived Message
type for this repeated field. The goal is to call
Reflection::AddMessage(), then recursively call my XmlToProto()
routine on this new object, parsing any children in the XML tree.
I was looking for a method in either the Descriptor or Reflection
interfaces to allocate a new object of the right Message-derived type
(obviously it would have to then return it a a Message*, which is
fine), but didn't see anything. Can someone point me in the right
direction?
Thanks in advance,
-Jason
On Sep 29, 6:06 am, sim simon.we...@gmail.com wrote:
Cool. New syntax I didn't know about! I think this would be useful
for converting the other way around (Proto-to-XML).
On Sep 28, 6:05 pm, Kenton Varda ken...@google.com wrote:
Interesting.
Another way to do this would be to write code based on protobuf reflection
and custom options, so you could have a proto like:
message Foo {
optional int32 i = 1 [(xml_disposition) = ATTRIBUTE];
optional Bar bar = 2 [(xml_disposition) = ELEMENT];
}
On Mon, Sep 28, 2009 at 6:14 AM, sim simon.we...@gmail.com wrote:
Hi all. Would anybody be interested in an XML to Protocol Buffers
converter if it were opened up to the community? I have an XML
stylesheet that transforms an annotated XSD set into a Java class that
uses JAXB and the Protocol Buffers Java API to convert XML documents
into either text or binary mode Protocol Buffers messages. The XSD
annotations define the mappings from XSD elements to Proto messages
(although at present staying close to a 1:1 mapping is probably
safest). Some fancy XSD features are not yet supported but the usual
complexTypes, simpleTypes, elements, and enumerations work.
Simon Weeks
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Add another option to support java_implement_interface
For some reason this thread got forked: here is the second copy: http://groups.google.com/group/protobuf/browse_thread/thread/c4efd9f017d0b014?hl=entvc=2 -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Add another option to support java_implement_interface
Kenton, Those are all good points, I agree with you that this kinda coupling could be dangerous and cause trouble if mismanaged. I'm trying to think of a way to keep this protoc safe but at the same time provide the kind of functionality the interface declaration would bring. Problem is that having the interface support requires the code to be actually compiled with the interface declaration, so nothing along the lines of doing something magical with dynamic proxies or anything like that seem like it would work (without using the reflection that is). Anything proposed by Chris with separating the declarations via java_ext that might work? How about some sort of a templating support maybe (I remember we were discussing that at some point for the setOrClear support)? -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
