[protobuf] protocol buffer message that accepts a variety of different arguments
Hi,
I would like to create a protocol buffer message that accepts a
variety of different arguments (including other messages). I can see
two obvious ways to do that:
message ArgInt32 {
required int32 arg = 1;
}
message ArgInt64 {
required int64 arg = 1;
}
//...
message ArgMessage {
required bytes arg = 1;
}
message Arguments {
repeated bytes argument = 1;
}
Where argument is serialized one of the predifined argument messages.
Or
message Arguments {
repeated int32 arg_int32 = 1;
repeated int64 arg_int64 = 2;
//...
repeated bytes arg_bytes = 100;
}
Is there better way to do that? If not based on your experience which
you will prefer?
Thanks,
George
--
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: protocol buffer message that accepts a variety of different arguments
Thank you for your advice.
I’m implementing a component model that has a different type-system
than protocol buffer. For the connectors that are IPC or inter
technology I would like to base the serialization on protocol buffers.
There is always an option based on the IDL definition I to generate
specific protocol buffer messages that represent the exact argument
list per method, but this looks over kill for me.
Thank you again,
George
On Nov 16, 12:28 pm, Henner Zeller henner.zel...@googlemail.com
wrote:
You might want to look into extensions that allow to do this in a
typesafe manner.
http://code.google.com/apis/protocolbuffers/docs/proto.html#extensions
Whenever something is considered to be transferred in a 'generic' way,
this is often a design-smell alarm. What is what you attempt to do ?
On Tue, Nov 16, 2010 at 09:54, George george.georg...@hotmail.com wrote:
Hi,
I would like to create a protocol buffer message that accepts a
variety of different arguments (including other messages). I can see
two obvious ways to do that:
message ArgInt32 {
required int32 arg = 1;
}
message ArgInt64 {
required int64 arg = 1;
}
//...
message ArgMessage {
required bytes arg = 1;
}
message Arguments {
repeated bytes argument = 1;
}
Where argument is serialized one of the predifined argument messages.
Or
message Arguments {
repeated int32 arg_int32 = 1;
repeated int64 arg_int64 = 2;
//...
repeated bytes arg_bytes = 100;
}
Is there better way to do that? If not based on your experience which
you will prefer?
Thanks,
George
--
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
athttp://groups.google.com/group/protobuf?hl=en.- Hide quoted text -
- Show quoted text -
--
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.
Re: [protobuf] Re: omitting tag numbers
On Tue, Nov 9, 2010 at 10:42 PM, Christopher Smith cbsm...@gmail.comwrote: This aspect could be mostly mitigated by integrating a metadata header in to files. For systems with this kind of an approach look at Avro Hessian. Problems with that: 1) Protobufs are routinely used to encode small messages of just a few bytes. Metadata would almost certainly be larger than the actual messages in such cases. 2) This metadata would add an extra layer of indirection into the parsing process which would probably make it much slower than it is today. 3) Interpreting the metadata itself to build that table would add additional time and memory overhead. Presumably this would have to involve looking up field names in hash maps -- expensive operations compared to the things the protobuf parser does today. -- 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.
Re: [protobuf] Re: python enum values option
That is strange. Can you provide a minimal but complete program that
reproduces this problem, so I can look at it?
On Wed, Nov 10, 2010 at 12:42 AM, Vsevolod Zadubrovsky
zadubrov...@gmail.com wrote:
It seems to me, it doesn't work at all.
I got this:
(Pdb) import ooo
(Pdb) vals_by_nums =
req.DESCRIPTOR.fields_by_name['error'].enum_type.values_by_number[req.error]
(Pdb) options = vals_by_nums.GetOptions()
(Pdb) options.Extensions[ooo.verbose_enum_value_option]
*** KeyError: 'Extension verbose_enum_value_option extends message
type google.protobuf.EnumValueOptions, but this message is of type
google.protobuf.EnumValueOptions.'
I've checked the source code, and it looks like raised from here
(google.protobuf.reflection, line 224):
if extension_handle.containing_type is not message.DESCRIPTOR:
raise KeyError('Extension %s extends message type %s, but this
'
'message is of type %s.' %
(extension_handle.full_name,
extension_handle.containing_type.full_name,
message.DESCRIPTOR.full_name))
Any ideas ? may be it is already solved in trunk version?
Thanks
On Nov 10, 1:50 am, Kenton Varda ken...@google.com wrote:
You need to use the descriptor for the enum type. Unfortunately this
interface isn't very well fleshed-out in Python. I think you'd have to
write something like:
Request.DESCRIPTOR.fields_by_name['error'].enum_type.values_by_number[message.error].options.Extensions[verbose_enum_value_option]
I haven't checked that that's exactly correct, but it gives you an idea.
We
should probably improve this.
On Tue, Nov 9, 2010 at 4:12 AM, Vsevolod Zadubrovsky
zadubrov...@gmail.comwrote:
Hi, I'm stuck with getting the enum value option in Python. The proto
file is:
import descriptor.proto;
extend google.protobuf.EnumValueOptions {
optional string verbose_enum_value_option = 50005;
}
enum ErrorType {
OK = 1 [(verbose_enum_value_option) = OK];
SOME_ERROR = 2 [(verbose_enum_value_option) = Some Error
verbose
message];
}
message Request {
required bool success = 1;
optional ErrorType error = 2;
}
When I receive the Request message, I can access the 'error' field,
and its type is int, that's actually ok. But how can I get the
verbose_enum_value_option of 'error' field value ?
Thanks
p.s. The goal is to keep error types and their verbose error messages
in one place, available for every service in our project, so the error
messages would've been identical.
--
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.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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: Swap() on Windows
On Wed, Nov 10, 2010 at 6:51 PM, Anand Ganesh anantharamangan...@gmail.comwrote: Hi Kenton, all, When you have a message which contains a string member variable, the variable is initialized to a default-value. So you have ::std::string *name_; static const ::std::string _default_name_; name_ = _default_name; Seems like since _default_name is declared 'const' the microsoft compiler is optimizing for cache localization and putting _default_name_ inside each individual object (like it would for a member variable). Hence _default_name_ has different addresses in two different objects. Functionally this is not a problem because there's no data-sharing (as in, one object modifying the static variable to a new value and others reading the new value from it) because it is declared const. This doesn't make sense. _default_name_ is only defined once, in the .pb.cc file. The compiler should only be compiling that file once, and therefore should only be producing one instance of the object. Other translation units which #include your .pb.h cannot possibly have their own definition of _default_name_ because they don't know what it should be initialized to. So the only way this is possible is if you are actually linking together two separate instances of the same .pb.o file. Perhaps you have statically linked your .pb.o into two different DLLs, and you are then trying to pass objects between them? This will not work -- they need to share a single instance of the object file. This problem is not unique to protocol buffers; it is generally unsafe to link two copies of the same class into one process and expect them to be compatible. You will either have to link the .pb.o file into a DLL that can be shared by the other two, or (probably safer) you could serialize the message before passing it across the DLL boundary and then parse it again on the other side. See also the warnings about DLLs in vsprojects/readme.txt. -- 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.
Re: [protobuf] The generated java code crashes if I try to integrate it into an Eclipse Rich Client application
The generated code contains a big string literal which contains metadata about the types. The metadata is itself a protocol buffer, and is decoded at startup. It looks like it is somehow being corrupted in your environment. I don't know how that would happen. I recently wrote an Eclipse plugin that used protocol buffers and did not see any problems. That said, you can try adding this to your .proto file: option optimize_for = LITE_RUNTIME; This turns off a number of features, including self-description. Thus, the generated code will no longer contain an embedded descriptor at all. On Thu, Nov 11, 2010 at 11:00 AM, Alsmom2005 gundanu...@gmail.com wrote: Hi, I have problems integrating Java GPB generated code into an Eclipse Rich Client Platform Application. The same code works fine in a standalone java project but it crashes in the RCP environment at the first 'usage' of an enum value defined in GPB code: Exception in thread Thread-3 java.lang.ExceptionInInitializerError at com.google.protobuf.DescriptorProtos $FileDescriptorProto.clinit(DescriptorProtos.java:1687) at com.google.protobuf.Descriptors $FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java:338) at NGCMOSMsg.NGCMOSMessages.clinit(NGCMOSMessages.java:11255) at NGCMOSMsg.NGCMOSMessages$MOSEndpoints.clinit(NGCMOSMessages.java: 353) at communication.PostOffice.init(PostOffice.java:31) at communication.PostOffice.getPostOffice(PostOffice.java:106) at ca.mda.moscs.common.Utilities$1.run(Utilities.java:130) Caused by: java.lang.IllegalArgumentException: Failed to parse protocol buffer descriptor for generated code. at com.google.protobuf.Descriptors $FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java:341) at com.google.protobuf.DescriptorProtos.clinit(DescriptorProtos.java: 12656) ... 7 more Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol message tag had invalid wire type. at com.google.protobuf.InvalidProtocolBufferException.invalidWireType(InvalidProtocolBufferException.java: 86) at com.google.protobuf.UnknownFieldSet $Builder.mergeFieldFrom(UnknownFieldSet.java:600) at com.google.protobuf.GeneratedMessage $Builder.parseUnknownField(GeneratedMessage.java:320) at com.google.protobuf.DescriptorProtos$DescriptorProto $Builder.mergeFrom(DescriptorProtos.java:2742) at com.google.protobuf.DescriptorProtos$DescriptorProto $Builder.mergeFrom(DescriptorProtos.java:1) at com.google.protobuf.CodedInputStream.readMessage(CodedInputStream.java: 285) at com.google.protobuf.DescriptorProtos$FileDescriptorProto $Builder.mergeFrom(DescriptorProtos.java:1143) at com.google.protobuf.DescriptorProtos$FileDescriptorProto $Builder.mergeFrom(DescriptorProtos.java:1) at com.google.protobuf.AbstractMessage $Builder.mergeFrom(AbstractMessage.java:288) at com.google.protobuf.AbstractMessage $Builder.mergeFrom(AbstractMessage.java:1) at com.google.protobuf.AbstractMessageLite $Builder.mergeFrom(AbstractMessageLite.java:184) at com.google.protobuf.AbstractMessage $Builder.mergeFrom(AbstractMessage.java:792) at com.google.protobuf.AbstractMessage $Builder.mergeFrom(AbstractMessage.java:1) at com.google.protobuf.AbstractMessageLite $Builder.mergeFrom(AbstractMessageLite.java:174) at com.google.protobuf.AbstractMessage $Builder.mergeFrom(AbstractMessage.java:785) at com.google.protobuf.DescriptorProtos $FileDescriptorProto.parseFrom(DescriptorProtos.java:820) at com.google.protobuf.Descriptors $FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java:338) ... 8 more java.lang.NullPointerException at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper $ComponentPresentationCache.getCacheFile(ComponentPresentationHelper.java: 428) at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper $ComponentPresentationCache.init(ComponentPresentationHelper.java: 322) at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper.getCache(ComponentPresentationHelper.java: 299) at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper.access $0(ComponentPresentationHelper.java:295) at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper $1.run(ComponentPresentationHelper.java:504) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) java.lang.NullPointerException at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper $ComponentPresentationCache.getCacheFile(ComponentPresentationHelper.java: 428) at com.instantiations.designer.core.xml.model.description.ComponentPresentationHelper
Re: [protobuf] Build error on HPUX11.11 with aCC(HP ANSI C++ B3910B A.03.37)
It's possible that aCC does not correctly implement the C++ standard. Templates are really complicated and few compilers get them completely right. Unfortunately all I can say is if you get it working, send a patch. We do not use this compiler at Google so I can't test it myself. On Fri, Nov 12, 2010 at 1:38 AM, Xray renxi...@gmail.com wrote: Hi, Everybody I'm trying to build protobuffer on HPUX with aCC, but can't made it successfully. First of all, I run ./configure CXXFLAGS=-ext -AA -D__osf__, then make. aCC reports that it can't recorgnize a line in google/protobuf/ stubs/common.h: aCC -DHAVE_CONFIG_H -I. -I..-D_REENTRANT -ext -AA -D__osf__ -c - o main.o `test -f 'google/protobuf/compiler/main.cc' || echo './'`google/protobuf/compiler/main.cc Error 20: ./google/protobuf/stubs/common.h, line 314 # 'type name' expected before ''. template bool ^ So I try to modify common.h by changing it from template bool to template bool b Then I make again, and it passed through, but a while later, many other error information appears: libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -ext -AA - D__osf__ -c +Maked google/protobuf/stubs/hash.cc -o hash.o /dev/null 21 source='google/protobuf/extension_set.cc' object='extension_set.lo' libtool=yes \ DEPDIR=.deps depmode=hp2 /bin/sh ../depcomp \ /bin/sh ../libtool --tag=CXX --mode=compile aCC - DHAVE_CONFIG_H -I. -I..-D_REENTRANT -ext -AA -D__osf__ -c -o extension_set.lo `test -f 'google/protobuf/extension_set.cc' || echo './'`google/protobuf/extension_set.cc libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -ext -AA - D__osf__ -c +Maked google/protobuf/extension_set.cc +Z -DPIC -o .libs/ extension_set.o Error 173: ./google/protobuf/repeated_field.h, line 800 # Redefined symbol 'TypeHandler'; previously defined at [./google/protobuf/repeated_field.h, line 796]. class RepeatedPtrFieldstring::TypeHandler ^^^ Error 219: ./google/protobuf/repeated_field.h, line 891 # Cannot return value where return type of function is void. return RepeatedPtrFieldBase::AddClearedTypeHandler(value); Error 219: ./google/protobuf/repeated_field.h, line 901 # Cannot return value where return type of function is void. return RepeatedPtrFieldBase::Reserve(new_size); ^^^ Warning 921: ./google/protobuf/wire_format_lite.h, line 89 # A trailing comma is not allowed in an enumeration. WIRETYPE_VARINT = 0, ^^ .. It was really confusing, was it beacuse of some options of aCC I didn't set correctly? Pls kindly help, thanks! -- 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.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- 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: Issue 235 in protobuf: ImportError: No module named google.protobuf
Updates: Status: CannotReproduce Comment #1 on issue 235 by ken...@google.com: ImportError: No module named google.protobuf http://code.google.com/p/protobuf/issues/detail?id=235 I am not able to reproduce this with Python 2.6.5. You'll have to provide more information. -- 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.
Re: [protobuf] extending enums
There is no explicit support for this. You can, of course, just use an
integer instead.
On Sat, Nov 13, 2010 at 8:10 AM, sabretoothedhamster
sabretoothedhams...@gmail.com wrote:
Hello everyone!
Is there any way to extend not only a message, but an enum also? E.g.
having the example from
http://code.google.com/apis/protocolbuffers/docs/techniques.html
I would like to keep OneMessage description separated into two files.
Core part with Foo and Bar descriptions in one .proto file (like in
the second pre section), and the second .proto file with Baz
description. It is clear how to organize this on a message level, but
I would like also to have enum Type { FOO = 1; BAR = 2; } in the first
file, and enum Type { BAZ = 3; } in the second. Is it possible at all?
Any workarounds?
--
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.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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.
Re: [protobuf] Visual Studio 2010
I test every release on MSVC (2005 and 2008; 2010 wasn't around yet when 2.3.0 was released). I did not see these problems. What version are you using? You could try downloading the latest version of gtest from googletest.googlecode.com and replacing the gtest directory with it. Note that as of the last release, the VS projects for gtest needed a couple small tweaks to the linker settings -- see the autogen.sh in the top-level protobuf dir which (among other things) applies these tweaks. On Sun, Nov 14, 2010 at 9:06 AM, GDotBookGenius gdotthe...@gmail.comwrote: I am trying to built the VS solution under the protobuf-2.3.0/ vsprojects folder, but it comes up with errors. 2549 of them to be exact. It seems to onl y be the test projects that fail to build (gtest, gtest_main, test_plugin, tests, lite_test). The problem seems to be with the template classes defined in gtest-tuple.h. The warning at the top of this file says it was generated by a script. Which script was it? How can I fix this? -- 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.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- 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.
Re: [protobuf] Parse from a iterator range possible?
I think your best bet is to construct an std::string from the iterator range, and then parse from that. STL-style iterators are awkward because they achieve polymorphism via templates. In order for the protobuf parser to be able to use arbitrary iterators directly, the whole parser would have to be an enormous template. This would be impractical for a lot of reasons. On Mon, Nov 15, 2010 at 1:30 PM, idleman evoo...@gmail.com wrote: Hello everyone, I am just wondering if it should be possible to parse from a iterator range? Say something like this: template typename FowardIterator bool ParseFromRange(ForwardIterator, ForwordIterator); Is it possible? Could it easily be implemented? Thanks in advance! -- 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.comprotobuf%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- 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.
Re: [protobuf] Re: protocol buffer message that accepts a variety of different arguments
On Tue, Nov 16, 2010 at 1:28 PM, George george.georg...@hotmail.com wrote: Thank you for your advice. I’m implementing a component model that has a different type-system than protocol buffer. For the connectors that are IPC or inter technology I would like to base the serialization on protocol buffers. There is always an option based on the IDL definition I to generate specific protocol buffer messages that represent the exact argument list per method, but this looks over kill for me. That's the way protocol buffers are intended to be used. I.e. you would have unique input and output types for every method. Trying to have a generic type defeats a lot of the purpose of protocol buffers -- you lose the type safety, some of the efficiency, the forward- and backwards-compatibility, etc. -- 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] memory usage problem of using a group record
I try to use the pb to store a group of record with the same schema. I wonder to know whether the key of the properties would be copied for every record like mapkey, value. if like this, it seems to a waste of memory. -- 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.
Re: [protobuf] Re: omitting tag numbers
On Tue, Nov 16, 2010 at 7:28 PM, Kenton Varda ken...@google.com wrote: On Tue, Nov 9, 2010 at 10:42 PM, Christopher Smith cbsm...@gmail.comwrote: This aspect could be mostly mitigated by integrating a metadata header in to files. For systems with this kind of an approach look at Avro Hessian. Problems with that: 1) Protobufs are routinely used to encode small messages of just a few bytes. Metadata would almost certainly be larger than the actual messages in such cases. 2) This metadata would add an extra layer of indirection into the parsing process which would probably make it much slower than it is today. 3) Interpreting the metadata itself to build that table would add additional time and memory overhead. Presumably this would have to involve looking up field names in hash maps -- expensive operations compared to the things the protobuf parser does today. Sorry, wasn't meaning to suggest that changes be made to protobuf. Mostly just meaning that if that you want that, there are other solutions that are a better fit. I think Avro in particularly has a solution that mitigates drawbacks 1-3, at the expense of some additional complexity. You can hack this in to a protobuf solutions though. You just encode the FileDescriptorSet in to your file header. Then when you start a scan, you read it in, find out the field numbers that correspond to the field names you want, and then parse the protobuf's as before. The key thing is the overhead is only once per file (which presumably has tons of small messages) and that you transform the parse/query after reading the header to exactly what you'd have had if you used the field numbers to start with. Honestly, for me the win with the field numbers tends to be with long term forward and backward compatibility. -- Chris -- 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.
