Protocol Buffers Google open source project discussion ()

Holger Rusch | 23 May 2013 12:22

Which C version of protobuf?

Hi,

which of the many floating versions of protobuf for C do you suggest if i need to stick with C?

For me https://code.google.com/p/protobuf-embedded-c/ seems to be the only one which is still ongoing an able to manage most of 2.5.0.

What do you suggest?

Thanks!

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

Ruffian Eo | 23 May 2013 17:48

Who needs "import public" ?

I am currently updating my years old implementation of protocol buffers for my company. Handwritten parser and code generators etc...

So while reviewing the current state of the art, I was taken by surprise when I saw the (for me) new "import public" construct.

Maybe what is written about this construct is not sufficient on the documentation page (It only gives a rather esoteric "dummy-header" example at the time of writing this topic).

Semantics beyond that example can only be guessed.

Let's assume there are 3 .proto files:

// File A.proto

package A;

message Base

{

required string hello = 1;

}

// File B.proto

package B;

import "A.proto";

message UsesABbase

{

required A.Base greeting = 1; // legal or only legal if above "import public "A.proto";?

required string something_else = 2;

}

// File C.proto

import "B.proto";

message MyMessage

{

required B.UsesABase my_element = 1;

}

Given that B imported (contrary to import public) A.proto and used A.Base for the definition of B.UsesABase message, is this a legal scenario?

When would B.proto do a "private import"? Is there any useful scenario if the above sample is not legal?

Why was import public added instead of a "import private" statement with import being as it used to be? (like #include in c) and "import private" having a new meaning?

I am not sure if I am happy about "import public" at all. To me it looks like a "fix in the wrong place", trying to avoid cyclic includes or something.

I also see no profit of this new feature if it comes to generated (c++) code: the generated headers still have to be added to the #includes of each header file.

Imho, in both cases, the include list of C.proto and B.proto -> .h files looks exactly the same, no matter if B.proto wrote import "A.proto" or import public "A.proto".

I guess my tool chain will simply treat import public just like import and check for cyclic imports and handle it as if on top of each .proto stood "#pragma once" ;)

Constructive comments and scenarios where import public can be beneficial are welcome!

Sidenote: Is import "subfolder\XY.proto"; (with backslash) a legal statement?

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

Ruffian Eo | 23 May 2013 18:31

New syntax for packed message elements: Example. packed uint32 my_element = 1;

Ever since I first used protocol buffers, the construct [packed=true] appeared like a temporary hack to me.

Here my proposal:

Alternate syntax (with same constraints and semantics)

Example Old:

repeated uint32 my_element = 1 [packed=true];

Example New:

packed uint32 my_element = 1;

Advantages:

- Improved semantics. Since the encoding is entirely different for repeated and packed=true collections, this is not really an option (as in a minor tweak) - it is something different.

- Easier to parse. For tools, the new syntax allows to treat all possible elements in a more consistent style (required, repeated, optional, packed). While at this level there is already a small semantic collision (required/optional address versioning, repeated addresses "collections"), the packed syntax would not make it worse.

- Easier to read.

- Easier to write.

- Clear separation from "other options".

I propose to first add the new packed syntax as possible, later to deprecate the [packed=true] and eventually to remove [packed=true] and have the new syntax alone.

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

Christopher Molozian | 23 May 2013 13:17

Proxy multiple Protobuf TCP streams through single TCP connection and dispatch correct deserializer

Hi,

I'm currently using Netty with it's Protobuf Decoder (and Encoder) support to pass data between components in my application architecture. It's working very well.

I'm at the stage where I'd like to expose one TCP connection to my web frontend which can serialize and de-serialize protobuf messages to a variety of different components.

I have Component A which establishes the connection to the WebFrontend.

Component B and, Component C establish a TCP connection each to Component A.

Messages are sent from the WebFrontend to Component A which unwraps them and dispatches them to the correct component (B or C). Response messages are sent from B or C and wrapped to be sent to the WebFrontend by Component A. The problem I'm having is how to wrap the response message to be sent to the WebFrontend so it knows "oh, this came from Component A, let me deserialize it to this type."

Apologies if this is unclear, ask me any questions and I'll add as much relevant detail as I can.

Any advice or suggestion for software tools or libraries that already provide this "proxy" functionality is greatly appreciated.

Cheers,

Chris

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

Justin | 22 May 2013 17:05

Attempting to build generic Message from serialized data regardless of type (c++)

I'm receiving a serialized message over middleware (qpid), and I want to be able to instantiate a Message object in my base class which does not know the actual message type. I have a feeling this isn't actually possible, and I can easily workaround this by just passing the serialized message to the subclass instead of a Message object, but I would rather do it this way if possible.

Here is the relevant code snippet:

namespace GPB = google::protobuf;

// Check the queue for a message

qpid::messaging::Message message = amqpReceiver_.fetch(qpid::messaging::Duration::SECOND * 1);

std::string msgContent = message.getContent();

// Build a generic GPB message, without caring about the type.

// Step 1: Create a message factory

GPB::DynamicMessageFactory factory;

// Step 2: Build a descriptor based on the message content

GPB::Descriptor typeDescriptor(msgContent);

// Step 3: Use the factory to make us an instance of the appropriate message type

GPB::Message *gpbMessage = factory.GetPrototype(typeDescriptor).New();

handleMessage(gpbMessage);

This is all surrounded by a try/catch block, of course and I clean up memory after this.

The handleMessage(Message *) method is a pure virtual that the subclasses implement depending on type. The qpid stuff is largely irrelevant, I just wanted to include mention of where it is coming from.

My issue lies in the "Step 2", where I don't actually know how to make it work. The variable msgContent contains the serialized GPB message, but this class has no way of knowing the type. Is this even possible? I am pretty new to GPB, so I'm not sure if the serialized data even has enough information in it to allow generic deserialization and I'm partially assuming that it does not, but I'm hoping it does.

I have read a bunch of stuff on forums, etc. regarding FileDescriptorProto and DescriptorPool, which may be part of the answer, but I'm not getting the whole picture yet.

Thanks for any help you can offer!

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

Hubert Jagodziński | 22 May 2013 09:12

PHP Protobuf

Hi,

PHP Protobuf is another Protocol Buffers PHP implementation. It is written as extension in C providing high performance. The project is on Github here:

https://github.com/allegro/php-protobuf/

Could you add it to the Third Party Add-Ons wiki page?

I suppose it would go under the "PHP" programming language section.

regards,

Hubert

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

protobuf | 21 May 2013 16:13

Re: Issue 148 in protobuf: RFE: Support Documentation option in proto files and javadoc in generated Java files


Comment #10 on issue 148 by r.vaneet... <at> iterend.com: RFE: Support  
Documentation option in proto files and javadoc in generated Java files
http://code.google.com/p/protobuf/issues/detail?id=148

Thanks for the quick response ... I will apply it right now :)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--

-- 
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

protobuf | 21 May 2013 15:18

Re: Issue 148 in protobuf: RFE: Support Documentation option in proto files and javadoc in generated Java files


Comment #9 on issue 148 by jakob.ha... <at> exthex.com: RFE: Support  
Documentation option in proto files and javadoc in generated Java files
http://code.google.com/p/protobuf/issues/detail?id=148

I saw basic support for javadoc as suggested in #7 is already included  
since proto 2.5.0

message Message {
	optional string field = 1; // a string
}

is now converted to

/**
  * <code>optional string field = 1;</code>
  *
  * <pre>
  * a string
  * </pre>
  */

as javadoc for at least getters and setters in the generated Message and  
MessageBuilder classes

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--

-- 
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

protobuf | 21 May 2013 15:09

Re: Issue 148 in protobuf: RFE: Support Documentation option in proto files and javadoc in generated Java files


Comment #8 on issue 148 by r.vaneet... <at> iterend.com: RFE: Support  
Documentation option in proto files and javadoc in generated Java files
http://code.google.com/p/protobuf/issues/detail?id=148

Usefull functionnality to publish a proto within a team

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--

-- 
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

EWO | 21 May 2013 03:04

List of projects/products using protobuf?

Is there a list somewhere of projects or products that use protobuf? I am being asked to justify choosing protobuf for a new project and one aspect is adoption by others. Thanks in advance for any feedback.

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

headers

lakhan.pandya91 | 20 May 2013 18:06

about authenticating my post

Hey guys,
If you think my post is not legitimate or the issue is already raised then please give me the link of that issue. else I am a real guy and please accept my issue. I am using protobuf 2.5.0. Please contact me on lakhan.pandya91 <at> gmail.com

thank you.

--
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+unsubscribe <at> googlegroups.com.
To post to this group, send email to protobuf <at> googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

88	May 2013
148	April 2013
179	March 2013
152	February 2013
166	January 2013
181	December 2012
41	November 2012
59	October 2012
88	September 2012
103	August 2012
106	July 2012
78	June 2012
80	May 2012
88	April 2012
59	March 2012
94	February 2012
71	January 2012
92	December 2011
66	November 2011
131	October 2011
109	September 2011
82	August 2011
188	July 2011
141	June 2011
122	May 2011
162	April 2011
152	March 2011
209	February 2011
186	January 2011
191	December 2010
175	November 2010
170	October 2010
138	September 2010
200	August 2010
201	July 2010
188	June 2010
158	May 2010
222	April 2010
271	March 2010
231	February 2010
254	January 2010
281	December 2009
204	November 2009
247	October 2009
203	September 2009
309	August 2009
229	July 2009
231	June 2009
207	May 2009
199	April 2009
253	March 2009
125	February 2009
141	January 2009
153	December 2008
126	November 2008
242	October 2008
255	September 2008
424	August 2008
135	July 2008