On Fri, Feb 22, 2013 at 10:08 AM, Deepak Goyal deepak.t...@gmail.comwrote:
Hi Jas,
I am new to protocol Buffer, and really need some quick help..below is
the issue.
I want to send JMS message from 1 java program to another java program
using protocol buffer. I am not able to parse GPB
Use mutable_repomessage()-set_nodeid... - see the C++ tutorial an intro to
the generated accessors.
https://developers.google.com/protocol-buffers/docs/cpptutorial
On Mon, Nov 5, 2012 at 1:59 AM, Javier Blesa Martínez heav...@gmail.comwrote:
Hi,
I have a protobuf definition:
message
To start with you need to use the qualify with the package as
google.protobuf.DescriptorProto. See the section on Name Resolution:
https://developers.google.com/protocol-buffers/docs/proto#packages
Assuming your paths are set up correctly it should work after that.
On Fri, Sep 28, 2012 at 2:19
No, default values for a message are not supported. Field defaults must be
defined directly within the enclosing message - otherwise you'd need
different versions of the generated class depending on the context.
On Sun, Sep 16, 2012 at 9:50 PM, JP largefl...@gmail.com wrote:
Hi Everyone,
The various *Descriptor classes provide type-definition information. Check
out the API reference for your specific language (for C++ it's in
descriptor.h, Java is Descriptors.java, etc)
On Sun, Sep 16, 2012 at 12:51 AM, JP largefl...@gmail.com wrote:
Hi All,
I searched the documentation
This has also been implemented internally and will be included in the next
release.
On Tue, Sep 11, 2012 at 6:07 AM, Jan Koriťák je...@pudr.com wrote:
Hello,
We would like to use Custom options for message fields in Python.
According to
It sounds like you may be looking for
https://developers.google.com/protocol-buffers/docs/techniques#union
Or are you looking for more information about the extensions API?
https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#extension
On Mon, Sep 3, 2012 at 7:33 AM,
Are you using the getFooBuilder() methods?
A common practice for tests is to use the TextFormat: you can write out the
string representation of the pb you want, and then parse into a PB object.
Or you could narrow the API of your methods under test to take only the
submessages that they need.
You would need to list out all the message types you want to use, and
maintain a map from their Descriptor to their default instance (accessible
with getDefaultInstance()). You can then call newBuilder or other
construction methods.
If you are ok with using a dynamic rather than generated message
You can also copy via serialization:
Protocal.parseFrom(dynamicmsg.toByteArray());
On Sun, Sep 2, 2012 at 8:32 PM, qtom zheng zhfnj...@gmail.com wrote:
i do like following, and id does success;
ListFieldDescriptor fieldlist =
dynamicmsg.getDescriptorForType().getFields();
You can control whether the vector is empty or not: you can reserve memory
for the vector based on the descriptor size, or reuse a vector previously
passed to ListFields - calling vector::clear() does not delete the
allocated memory.
Admittedly, the reflection code is not heavily optimized. But
The general practices for changing messages are listed here:
https://developers.google.com/protocol-buffers/docs/proto#updating.
On Wed, Sep 5, 2012 at 7:04 PM, Minhyuk Kwon mug...@gmail.com wrote:
Hello,
I have plan for introducing protobuf to in our products for passing
information of
Should have been:
why not just parse the data directly into the builder instead of the
dynamic message?
--
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
Yes, that is one of the primary motivations for protocol buffers.
On Tue, Aug 21, 2012 at 2:45 PM, marcelot mato...@gmail.com wrote:
Dear All,
I just read about Protocol Buffers as an option for serializing and
de-serializing objects in C++ and Python. I am wondering if I could
serialize
There are a few Ruby implementations listed at
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns - do any of those
fit the bill?
On Wednesday, July 18, 2012 4:38:42 PM UTC-7, coyo wrote:
I'm making no promises, but if someone hasn't offered yet, what I have
seen of protobuf has me
that path up two
directories and made the import statement relative as you suggested the
problem was resolved.
-Dan
On Monday, June 4, 2012 5:26:35 PM UTC-7, Jason Hsueh wrote:
The issue is import paths - the pre-generated versions of
descriptor.pb.{h,cc} are generated relative
Required-field checking is only recursively applied when a message is
present. If your top-level Message only contains NestedMessage, the
initialization code should not be checking the AnotherNestedMessage field
to make sure that that submessage has all required fields populated. Can
you provide a
This is a result of SourceTreeDescirptorDatabase not implementing
FindFileContainingSymbol() - it doesn't maintain an index of the types
available in the database within the database, just the list of files that
are available. This is a sufficient implementation for the proto compiler,
where one
The issue is import paths - the pre-generated versions of
descriptor.pb.{h,cc} are generated relative to the source root. Instead of
importing descriptor.proto, you should have something like
import google/protobuf/descriptor.proto;
This should make the code generator reference the declared
You should refer to the python API docs:
https://developers.google.com/protocol-buffers/docs/pythontutorial
https://developers.google.com/protocol-buffers/docs/reference/python-generated
As you've found the generated .py aren't really helpful - it just includes
metadata that is used along with
You should have the message type's Descriptors.Descriptor in order to have
gotten a DynamicMessage in the first place. That class is the equivalent of
the C++ Descriptor class and has a findFieldByName
No, C++ only has the asynchronous interface. You'd need to provide some
kind of synchronization primitive that can then be implemented as a Closure.
On Mon, May 7, 2012 at 11:46 AM, Sky hmonfa...@gmail.com wrote:
Hi dear members.
I'm wondered if there is Blocking RPCChannel in C++ service like
From https://developers.google.com/protocol-buffers/docs/encoding#types:
If you use int32 or int64 as the type for a negative number, the resulting
varint is *always ten bytes long*
Per the section's recommendation you should use sint32/sint64 if you expect
to have signed values.
On Tue, May 8,
Your proto file in the link looks incomplete. Have you checked the outer
class name option?
https://developers.google.com/protocol-buffers/docs/reference/java-generated#invocation
On Tue, May 8, 2012 at 12:25 AM, Kasper Revsbech krevsb...@gmail.comwrote:
Hi all
I have a mind wrapping problem
You would need to implement a ZeroCopyInpuStream around the socket. The
implementation's Next() method would basically wrap the socket's read_some
method, and yield the buffer and size of data that was read. Since Next()
should return false when there's no more data to read, you would just check
Have you profiled this program? I would be surprised if protobuf code
consumes a significant amount of time: all you are doing is setting the
field values.
If you want to minimize memory usage, you can probably flush your LogFile
periodically to the stream: as long as you don't write anything
In general protobuf doesn't try to provide these kinds of container
formats. Gzip*Stream is meant to deal with data that is valid gzip;
inserting frames to make it searchable would break the format. In the
archives you may find other references to the internal container file
format that Google
It's unlikely that we'd add more generated code to support this use case;
code size is something that's watched carefully when making changes to the
protobuf library.
However, you can get this behavior by preprocessing the message with
reflection; you could iterate over the fields; if a repeated
You can use something like the code below. FileDescriptor's interface has
methods to produce the FileDescriptorProto; you just need to walk the
dependencies.
FileDescriptorSet output;
const FileDescriptor* file_desc = ConcreteMessage::descriptor()-file();
for (int i = 0; i
Oops, actually you'll need to recursively copy the dependencies into the
FileDescriptorSet.
On Wed, Feb 22, 2012 at 9:42 AM, Jason Hsueh jas...@google.com wrote:
You can use something like the code below. FileDescriptor's interface has
methods to produce the FileDescriptorProto; you just need
The difficulty with this is that the parser would need to accept two
distinct wire types for each integer field. The parsing code would become:
if tag number is x:
if wire type is positive varint { ... }
if wire type is negative varint { ... }
This leads to larger code size and has potential
Do you mean getting the sub-builders by passing the
Descriptor.FieldDescriptor for the field you want, like what you would do
for Message.Builder.setField()? This sounds like a reasonable feature
request, though to be honest I'm not familiar enough with the Java code to
know how difficult this
You should make sure to destroy the CodedOutputStream before getting sizes
from ZeroCopyOutputStream. CodedOutputStream effectively asks for a buffer
from ZeroCopyOutputStream, and ByteCount() reflects the total count that
CodedOutputStream has asked for. Upon destruction, CodedOutputStream may
You only need to register the extensions that you want to use. Unknown
extensions will get preserved as unknown fields (at least in the C++ and
Java implementations; python does not support unknown fields), and when you
reserialize the message those will be included. The registered receivers
will
Can you provide a wrapper OutputStream in your Java code so you can
intercept the exact bytes that are written to the stream? It wasn't clear if
in your last attempt you had removed the ObjectOutputStream issue or not. I
would suggest first making sure that the bytes you receive on the C++ side
on the C++ side using Message::ParseFromString() ?
Or is it just that the above code is inncorrect? Could I use a
different charset?
2) However, the above code would work to send GPBs from Java to Java
as String representations over JMS for example, correct?
On Oct 6, 1:03 pm, Jason Hsueh
You could write our own decoder around CodedInputStream, manually reading
and skipping the messages that you don't care about. The other option is to
use an equivalent message definition
message XAsBytes {
repeated bytes y = 1;
}
And then manually decode the entry you want into Y.
On Thu, Oct
You need to use the SerializeToZeroCopyStream interface, since you want to
pass in a custom stream. You use GzipOutputStream just like any other
ZeroCopyOutputStream, except it needs to wrap the underlying stream
implementation. Since you mention writing to a gzip file, you might do
something
The closest thing is something like:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
You'd need to enumerate all the types either explicitly or via extensions.
Without some extra identifier the generated code has no way of knowing how
to interpret the data to produce the
What's your code snippet for serializing and parsing? The 0 enum value ends
up getting encoded as the null character: assuming this is in C++, I'd guess
that you're using some c-style string routines that are prematurely
terminating the string at the null character.
On Tue, Sep 13, 2011 at 1:39
It appears that the C++ listener code supports multiple types, but assumes
that the correct type can be determined by checking if parsing the
serialized string returns successfully. This is not a reliable way to detect
message types: in fact ParseFromString() only fails if the serialized data
is
No, the issue is one and the same. You cannot receive arbitrary serialized
bytes and determine what the message type is. You can do something
heuristically, but there is no way for you to be absolutely certain of the
message type simply by looking at encoded bytes.
Specific points in the code:
On Sat, Aug 27, 2011 at 6:00 PM, Nader Salehi sal...@alumni.usc.edu wrote:
Thanks for looking into the code. Please see my comments inline.
On 8/27/2011 17:07 Jason Hsueh writes:
No, the issue is one and the same. You cannot receive arbitrary
serialized
bytes and determine what
++ code sends the same message type
and data, and how the listener manages to know what type it is. But the type
determination snippet that you provided is incorrect: the type name needs to
be specified by the sender rather than inferred.
On Sat, Aug 27, 2011 at 7:08 PM, Jason Hsueh jas...@google.com
The python implementation is effectively all built around DynamicMessage.
The GeneratedProtocolMessageType in reflection.py metaclass allows you to
define message classes from descriptors. The problem is that it's difficult
to convert *DescriptorProtos to the Descriptor objects that you need.
What command are you using to invoke protoc? This sort of problem usually
occurs when you don't use the same root directory in protoc invocations. So
you should have something like:
protoc --proto_path .\ProtoTopDir A.proto
protoc --proto_path .\ProtoTopDir Dir\B.proto Dir\C.proto
I'm not sure
The descriptor building libraries handle cross linking. The message type
name must be defined in either the same file, or be available through one of
the file's imports.
On Wed, Jul 27, 2011 at 7:36 AM, Giancarlo Frison gfri...@chelab.comwrote:
if I call setTypeName(messageName), how protobuf
The assignment operator simply wraps CopyFrom, so the behavior is exactly
the same. Stylistically we prefer to use CopyFrom over =, because it can be
an expensive operation and = makes it look deceptively simple. The operator=
overload primarily exists for compatibility with STL, but of course
wrote:
Sounds interesting, do you have an example of doing this?
On Jul 9, 2:21 am, Jason Hsueh jas...@google.com wrote:
Echoing Chris's messages, we don't really want to get into supporting
arbitrary types in the core implementation. Various language-specific
annotations could be added
On Sun, Jul 10, 2011 at 7:07 AM, Enrico Viappiani viappi...@gmail.comwrote:
I've got a java server and a c++ client, client sends a message to the
server.
In a first moment we had the message structure made by simple format
like strings or integers, and the message sending/receiving with
You'll want to use the insertion points that are emitted by the code
generators in the core implementation. There are some references to these in
plugin.proto, but I'm not sure that we have a document listing all the
available insertion points. I believe that these insertion points are
available
, before building the protobuf. But can i get some assistance on
how to implement the same.
Thanks,
Gokul.
On Sat, Jul 9, 2011 at 5:02 AM, Jason Hsueh jas...@google.com wrote:
We don't support this at this time - the primary problem is that
specifying an allocator for C++ string's produces
Zero is reserved for historical reasons; it used to be used for propagating
error codes.
The wire format was designed with extensibility in mind; while in many
applications unknown fields won't be encountered, this support is critical
in many internal applications.
Note that simply adding a zero
You'll have to check with the developer of the C# implementation for
support, but it appears that this code is the initialization of the member
to the default value. My guess is the implementation's code generator looks
up the enum name of the default value, and assumes that the default value is
We don't support this at this time - the primary problem is that specifying
an allocator for C++ string's produces a completely new type. This means
allocators can't simply be injected into a particularly message instance;
instead it would have to be part of the message definition.
On Wed, Jul 6,
Echoing Chris's messages, we don't really want to get into supporting
arbitrary types in the core implementation. Various language-specific
annotations could be added, but doing this portably across languages would
be difficult. Supporting these types also complicate the reflection
I'm not familiar with the boost libraries you're using, but the use of
async_write and the stack-allocated streambuf looks suspect. If nothing
jumps out there, I would first check that the data read from the socket in
Java exactly matches the data on the C++ side.
On Sat, Jul 2, 2011 at 8:55 AM,
that it remains
valid until the handler is called.
On Wed, Jul 6, 2011 at 10:10 AM, platzhirsch
konrad.rei...@googlemail.comwrote:
I find it difficult to check this by so many messages. This approach
was suggested by some people already, I don't know how I would realize
this.
On Jul 6, 6:56 pm, Jason
describing, becase the message size.
But I'm able upload proto descripter to reciver, so I want to parse
incomming message using proto descripter.
Could you help me, how I can do it?
On Jun 23, 8:12 pm, Jason Hsueh jas...@google.com wrote:
Oh, I missed that you were reading the FileDescriptorSet
the FileDescriptorSet?
On Jun 22, 8:35 pm, Jason Hsueh jas...@google.com wrote:
On Wed, Jun 22, 2011 at 3:30 AM, slookin sloo...@gmail.com wrote:
I trying to develop flexible server for reciving message, i'm not
able to create java classes for each message type, but I can upload
proto
There's not enough information: see
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
On Thu, Jun 23, 2011 at 8:55 AM, mjs483 matt.shi...@gmail.com wrote:
Hi,
Is there any way to read a protobuf from a file input stream without
consuming the entire file? Say for
On Wed, Jun 22, 2011 at 3:30 AM, slookin sloo...@gmail.com wrote:
I trying to develop flexible server for reciving message, i'm not
able to create java classes for each message type, but I can upload
proto descripter on server. Of course client (sender) will use
generated java classes for
Your best bet is to look at the other C# projects; we don't maintain any C#
code. However, TextFormat in the C++ implementation does exactly this, so
you might be able to use that as a starting point. Of course the reflection
APIs may be different in the other implementations.
On Mon, Jun 20,
I didn't really go through the whole thread, so I might have missed
something, but it's not clear to me how you plan to distinguish different
values in the data stream. But protobuf's serialization primitives are in
CodedInputStream/CodedOutputStream.
On Mon, Jun 20, 2011 at 8:49 AM, gabor.dicso
On Sun, Jun 12, 2011 at 3:58 PM, Kavi targetn...@gmail.com wrote:
Basically the strings dummy and data are the same. So why does it
throw the error?? Somebody please suggest a fix.
Have you verified that these strings are actually the same? (By doing a
direct comparison, rather than printing
Does http://code.google.com/apis/protocolbuffers/docs/techniques.html#unionhelp?
On Mon, Jun 13, 2011 at 8:05 AM, fmaltman frank.malt...@googlemail.comwrote:
Hello.
What's the correct way to read a message from an input stream without
knowing which of the defined message types it will be? I
Yeah, this is really a build system feature. make/maven/etc should check
whether the proto compiler needs to be reinvoked.
On Thu, May 26, 2011 at 2:16 AM, Maurice Nicholson
maur...@mauricenicholson.com wrote:
Answering my own question :-)
Think I found what I need in the Maven plugin docs:
Haven't used stringbuf before, but it looks like that just sets the internal
buffer for the stringbuf. You are going through a few layers of buffering
here; you probably want to just directly use a ZeroCopyOutputStream
implementation that writes to the socket, like FileOutputStream, which
allows
Jumping in late to the thread, and I'm not really a Java person, so I may be
misunderstanding something here. But as far as I can tell, you are asking
for hashCode() to be a 'consistent' hash across processes. hashCode() as
implemented is still useful within a single JVM, allowing you to use
Ah, I didn't get this message. How does this break use in a HashMap? Given
two protobufs of the same type in the same JVM, with the same contents, does
hashCode() not return the same value?
On Wed, May 18, 2011 at 11:50 AM, Jay Booth jaybo...@gmail.com wrote:
I'd also note that this precludes
On Wed, May 18, 2011 at 12:08 PM, Ron Reynolds tequila...@ymail.com wrote:
the corner-stone of Hash* containers is:
(A.equals(B)) = (A.hashCode() == B.hashCode()) for all A, B.
From what Ive gathered, this invariant is true for protocol buffer's
implementation of equals() and hashCode(). The
that the
element in question has been placed into another bucket because the
hashCode()
within the containing JVM has evaluated to another value. that's a
pretty
far-fetched, but not unimaginable, situation.
From: Jason Hsueh jas...@google.com
To: Jay Booth
for the use case here and is easier for corresponding
command-line tools, I just generally see a consistent hashcode as a
good idea if supportable.
On Wed, May 18, 2011 at 3:33 PM, Jason Hsueh jas...@google.com wrote:
Well, hashing the serialization as Pherl/Kenton suggested gives you
Ignore the data (sort of): The unknown value gets treated as an unknown
field, leaving the enum field unset. In implementations that support
propagation of unknown fields (non-lite C++, Java), the value is added to
the UnknownFieldSet.
Implications:
- a sender may set a required enum field to a
On Fri, Apr 15, 2011 at 2:06 AM, platzhirsch
konrad.rei...@googlemail.comwrote:
My problem is to serialize protobuf data in C++ and deserialize the
data in Java probably. In fact I get **InvalidProtobufferException**
in Java.
Here is my minimal example:
My protobuf file looks like this:
On Fri, Apr 15, 2011 at 9:48 AM, platzhirsch
konrad.rei...@googlemail.comwrote:
Right! I think I refactored the whole writing and reading, still I am
stuck. However by this I get this Exception:
com.google.protobuf.UninitializedMessageException: Message missing
required fields: name
In C++:
Protobufs reflection support allows you to do this. We don't have a
walkthrough, but you can create types dynamically using the Descriptors
classes along with DynamicMessage. You can build the definitions you want
into a FileDescriptorProto (along with any dependencies it may have) and
call
yup, that's what I meant. Can you check that you are writing data to the
stream? Also, I didn't notice that you are writing the message length as a
header. Did you read that value from the socket prior to calling parse? The
Java-side parseFrom call should only be reading the data read by
Oh, of course, glad it worked.
Also I realized I was mistaken about CodedOutputStream: it doesn't do any
internal buffering; it's OstreamOutputStream that does (some other
ZeroCopyOutputStream implementations do as well). In any event, keep
destroying the streams before you send.
On Fri, Apr 15,
We have bandied about the idea of supporting maps for some time. Past
discussion:
http://groups.google.com/group/protobuf/browse_thread/thread/5b43b26dec43bf99
At the moment, you just have to build your own map structures around the
protobuf.
On Fri, Apr 8, 2011 at 2:56 PM, Felix
The Descriptor classes don't support this as typically we want to enforce
that the Descriptor objects are in fact the same instances. In the protobuf
code you'll see simple pointer comparisons.
You could convert the descriptors back to DescriptorProtos and compare
those: however, this won't
Also don't have enough Java-fu, but I'd thought this was basically how this
was solved: the messages override some function that cause the JavaVM to
serialize using protobuf serialization. I was under the impression that the
message internals would then no longer needed to implement Serializable.
I've added this to the ThirdPartyAddOns wiki page. Thanks for providing this
implementation!
On Tue, Apr 5, 2011 at 8:35 AM, Evan Lapisky evan.lapi...@gmail.com wrote:
Hi,
We've recently open sourced our Matlab compiler for Protocol Buffers.
It has been in use internally for a couple of
...@gmail.com wrote:
Ok I'll do, I asked to be sure if a recursive definition was
syntactically correct.
Can you please check if there is a test case or an example?
On Apr 1, 4:44 pm, Jason Hsueh jas...@google.com wrote:
You appear to be using a third party implementation for pure C. You'll
have
The proto compiler actually allows you to do this, but it perhaps shouldn't
as it semantically does not make sense. You don't have any guarantees that
each application is aware of the required extension; therefore you can't
really say that a message is invalid if it doesn't have that extension
*/
And during gcc build I got an /cidl_deviceManager_hint.h:25: error:
'cidl_resource_info_size_hint' undeclared here (not in a function)
error from the compiler.
On Apr 1, 2:05 am, Jason Hsueh jas...@google.com wrote:
Recursive definitions should work, though I'm not sure we have a test
case
to verify
The most common issue with Java and extensions is not passing an
ExtensionRegistry containing the extensions you want to the deserialization
method. However, you mention that the parse is failing: if you didn't
register the extensions, or didn't use an extension registry, then the data
would
It won't be a decode error as long as the enum field is not required. If an
application without the new values receive a message containing one of the
new enum values, it will treat the value as an unknown field. In the C++ and
Java implementations (Python doesn't propagate unknown fields), the
Does your memory allocator immediately release memory to the system?
Google's tcmalloc, for instance, does not, for performance reasons.
On Wed, Mar 30, 2011 at 3:22 AM, martin sowasdum...@googlemail.com wrote:
Hello everybody,
I've got a strange behaviour when using a message with a repeated
Recursive definitions should work, though I'm not sure we have a test case
to verify use in repeated fields. I know there is one for optional messages.
What result did you get?
On Tue, Mar 29, 2011 at 5:58 AM, zad emanuele.plac...@gmail.com wrote:
Is it possible to have in a message declaration
The protocol compiler just generates C++ code. How the enum is represented
in memory is entirely up to your C++ compiler. The standard allows the
compiler to choose the size of the enum (with the restriction that it should
be not more than sizeof(int)). I would guess that a typical compiler would
It's on the left bar of the home page: http://code.google.com/p/protobuf/ -
it's just a link to the New BSD
Licensehttp://www.opensource.org/licenses/bsd-license.php
.
On Wed, Mar 16, 2011 at 10:02 AM, Kelly kconley...@gmail.com wrote:
Hi, I can't find the Google Protocol Buffer license
On Wed, Mar 16, 2011 at 12:17 PM, steph preston@gmail.com wrote:
I want to have a bool value default to true but I cant seem to make it
do that. As stated in the protocol buffer documentation bools default
to false. However since i'm able to set default values on types i want
to set the
:
The error text i get is:
Error the .proto-file is invalid, content: optional bool
getA = 1 [default = true];, line number: 2
On Mar 16, 3:25 pm, Jason Hsueh jas...@google.com wrote:
On Wed, Mar 16, 2011 at 12:17 PM, steph preston@gmail.com wrote:
I want to have a bool value
On Mon, Mar 14, 2011 at 1:12 PM, steph preston@gmail.com wrote:
given the following:
message ClassA {
required int value1 = 1;
required int value2 = 2;
optional ClassB value3 = 3;
}
message ClassB {
required int value1 = 1;
required int value2 =
You wrap GZipOutputStream around your underlying output stream, and use the
GZipOutputStream with CodedOutputStream instead:
On Tue, Mar 8, 2011 at 10:10 AM, ksamdev samvel.khalat...@gmail.com wrote:
Hi,
Are there any examples on how to use GzipOUtputStream in ProtoBuf?
I've manages so far
I don't think there are any problems with having a raw prefix, and just
wrapping GZipInputStream around the raw input stream after it's been read,
but that sounds pretty messy. It seems easier to just make the whole thing a
gzip stream - it can then also be easily read by other tools that use
http://code.google.com/apis/protocolbuffers/docs/proto.html#services describes
how to define services. However, protobuf does not provide an RPC
implementation. You may set the file option {lang}_generic_services = true
to have the protocol compiler generate a stub that can be used to integrate
No, message inheritance is not supported. Have a look at
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union and
see if that solves your use case.
On Wed, Mar 2, 2011 at 7:04 AM, ZHOU Xiaobo xb.z...@qq.com wrote:
Hi:
My problem is that when I receive a packet I have to
Can you try patching r380? This fixed the issue for the previous
reporthttp://groups.google.com/group/protobuf/browse_thread/thread/36c08e9f2c4397b0/792ab77c4fbc09ffof
this error.
On Fri, Feb 25, 2011 at 2:13 PM, Shiv cjs...@gmail.com wrote:
Hi,
I'm trying to install protobuf on linux 64bit,
1 - 100 of 246 matches
Mail list logo
