Streaming
Hi, I am looking at a use case where one needs to transfer streaming data (video, file transfer etc..). Will PB support such a use case on its own? Thanks & Best Regards, Suresh --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: C# port has new layout
Thanks for the info Jon. Plus, with a pre-build protoc, I might be able to do some work on protobuf-net code-generation (I never did get VS working with the official version...). Marc --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Standard for RPC proto
This whole conversation (proto / rpc) seems to have been very quiet for a while. I'd be very keen to implement rpc for protobuf-net, so / any/ kind of consensus would be good. I suppose I'd default to the more Java compatible, but... Marc --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Data structures using protocol buffers
Sounds like fun. Just curious what is actually supposed to be encoded
in the protobuf message, if the graph is too big to fit in memory?
Are you sending just a single node, with its edges? It seems like you
wouldn't be able to avoid scenarios where some of the edges in your
message point to nodes that are not also serialized in your message,
given that you can't actually store the entire graph in memory, let
alone a protobuf message? What graph operations are you looking to
parallelize?
-dave
On Oct 23, 12:12 am, GDR <[EMAIL PROTECTED]> wrote:
> Thanks. I am trying to use protocol buffers with a map reduce
> framework to work on large graphs. The graphs are too big to fit in
> memory so building auxiliary data structures is difficult. Any ideas?
>
> On Oct 22, 2:48 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
>
> > Protocol Buffers are a serialization format, rather than general-purpose
> > data structures. To do computations, you'd probably want to build some
> > auxiliary data structures, which you populate when you deserialize the
> > protobuf data. You could have node objects that resemble your original
> > .proto file, where nodes have references to their neighbors, and you'd
> > probably need a map from node id to node object reference, which you'd
> > use during deserialization.
>
> > --
> > Jeremy Leader
> > [EMAIL PROTECTED]
>
> > GDR wrote:
> > > my bad. The code snippet should be as follows:
>
> > > for(UndirectedGraphNode node : UndirectedGraph.getNodesList() ) {
> > > double sum = 0;
> > > int count = 0;
> > > for(UndirectedGraphNodeReference neighbor :
> > > node.getNeighborsList() ) {
> > > sum +=
> > > count++;
> > > }
> > > node.setWeight(sum/count);
>
> > > }
>
> > > - graph.proto -
>
> > > package graph;
>
> > > option java_package = "graph";
> > > option java_outer_classname = "UndirectedGraphType";
> > > option optimize_for = CODE_SIZE;
>
> > > message UndirectedGraphNodeReference {
> > > required string id = 1;
> > > }
>
> > > message UndirectedGraphNode {
> > > required string id = 1;
> > > required double weight = 2;
> > > repeated UndirectedGraphNodeReference neighbors = 2;
> > > }
>
> > > message UndirectedGraph {
> > > repeated UndirectedGraphNode nodes = 1;
> > > }
>
> > > On Oct 22, 2:36 pm, GDR <[EMAIL PROTECTED]> wrote:
> > >> That does solve the duplicate information problem but it makes updates
> > >> to node attributes (like weight) difficult. Let's say, I want to
> > >> assign the weight of each node to the average of its neighbors.
>
> > >> for(UndirectedGraphNode node : UndirectedGraph.getNodesList() ) {
> > >> double sum = 0;
> > >> int count = 0;
> > >> for(UndirectedGraphNodeReference neighbor :
> > >> node.getNeighborsList() ) {
> > >> sum +=
> > >> count++;
> > >> }
> > >> node.setWeight(sum/count);
>
> > >> }
>
> > >> - graph.proto -
>
> > >> package graph;
>
> > >> option java_package = "graph";
> > >> option java_outer_classname = "UndirectedGraphType";
> > >> option optimize_for = CODE_SIZE;
>
> > >> message UndirectedGraphNodeReference {
> > >> required string id = 1;
> > >> required double weight = 2;
>
> > >> }
>
> > >> message UndirectedGraphNode {
> > >> required string id = 1;
> > >> repeated UndirectedGraphNodeReference neighbors = 2;
>
> > >> }
>
> > >> message UndirectedGraph {
> > >> repeated UndirectedGraphNode nodes = 1;
>
> > >> }
>
> > >> On Oct 22, 2:14 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
>
> > >>> I was assuming all the properties of a node (weight, label, color,
> > >>> whatever) would be in UndirectedGraphNode; UndirectedGraphNodeReference
> > >>> would only have the id and nothing else.
> > >>> --
> > >>> Jeremy Leader
> > >>> [EMAIL PROTECTED]
> > >>> GDR wrote:
> > Thanks Jeremy. That worked!
> > But we now have information about the same node being replicated. For
> > instance, let's say we have a field 'weight' attached to each node as
> > shown below. This setup will replicate the weight information of a
> > node as many times as its degree. If the weight of a node changes, I
> > will have update all it's occurrences in the PB. Any way I can avoid
> > it?
> > package graph;
> > option java_package = "graph";
> > option java_outer_classname = "UndirectedGraphType";
> > option optimize_for = CODE_SIZE;
> > message UndirectedGraphNodeReference {
> > required string id = 1;
> > required double weight = 2;
> > }
> > message UndirectedGraphNode {
> > required string id = 1;
> > repeated UndirectedGraphNodeReference neighbors = 2;
> > }
> > message UndirectedGraph {
> > repeated UndirectedGraphNode nodes = 1;
> > }
> > On Oct 21, 6:37 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
> > > Keep in mind that protobufs describe serialized data, and there's no
> > > concept of an object reference
Re: strings with fixed length
STL strings never shrink. When they're cleared, they keep their memory
around for reuse. So, you could take advantage of that to accomplish what
you want by setting all your string fields to values of the maximum size and
then clearing them. For example:
StaticSizeMsg msg;
msg.set_message(string(50, 'x'));
msg.Clear();
Now if you use msg to parse any message where the "message" field is <= 50
bytes, it will not do any allocation.
On Thu, Oct 23, 2008 at 4:17 AM, thecreator <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> I'd like to realize messages which do not need to allocate memory
> during runtime. All the allocation should be done
> at initialization. Therefor I'd need some mechanism to define strings
> with fixed length in .proto files.
>
> I read about the option annotation in version 2.0.2.
> Is it possible to change the code generation with this annotations, so
> that a string is not created as new std::string
> but also reserve the memory which is set in the option:
> e.g. in the proto file:
>
> message StaticSizeMsg
> {
> required string message = 1 [size = 50];
> }
>
> The generated code should like like this:
> std::string message_;
> message_.reserver(50);
>
> thanks,
> greets Ralph
> >
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Any way to dissect ProtBuf serialized data without knowing the structure in advance?
>From the command line, you can do: protoc --decode_raw < data_file This will give you as much information as can be determined without a type definition, to give you an idea of what's there. In C++, you can use the UnknownFieldSet class to parse and inspect a message of unknown type. On Wed, Oct 22, 2008 at 10:32 PM, <[EMAIL PROTECTED]> wrote: > > I'm trying to consume data from an app that generates output > serialized via Protocol Buffers but do not have the original spec for > the specific structures that have been encoded. Is there a relatively > straight-forward path to deserializing, or even just decoding, the > serialized data stream without knowing its structure in advance? > > Hints/pointers of any variety would be welcomed. > > Thanks. > > APB > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Where are the pre-compiled lib and supporting header files?
We do not provide a pre-compiled library because it is important that you use a version of the library compiled with the same compiler version which you will be using with your own code. Even on Windows, different versions of MSVC have slightly different STL implementations. Since the protocol buffer library uses STL in its interface, the app and the library have to be using identical STL implementations in order to be compatible. So, please just use your own compiler to compile the protobuf library. See the readme files for step-by-step instructions. On Thu, Oct 23, 2008 at 2:06 AM, sdx <[EMAIL PROTECTED]> wrote: > > Hi, > > I would be grateful if someone could point me in the right direction > (please see subject) > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Make check reports error
Cygwin allows you to specify paths like "C:\". For example, try this
command:
ls 'C:\'
At least, for me, this lists the root of the C drive. It looks like the
test failed because you do not have permission to access C:\ on your
machine. Is this possible? You can probably ignore this failure.
The sparc failure is still mysterious to me. Unfortunately I don't have a
sparc machine on which I can debug it. :(
On Thu, Oct 23, 2008 at 1:22 AM, Niclas Blomgren <
[EMAIL PROTECTED]> wrote:
> Hi again,
>
> I took a quick look at this code in command_line_interface_unittest.cc
>
> TEST_F(CommandLineInterfaceTest, WindowsOutputPath) {
> // Test that the output path can be a Windows-style path.
>
> NullCodeGenerator* generator = RegisterNullGenerator("--test_out");
>
> CreateTempFile("foo.proto",
> "syntax = \"proto2\";\n");
>
> Run("protocol_compiler --test_out=C:\\ "
> "--proto_path=$tmpdir foo.proto");
>
> ExpectNoErrors();
> EXPECT_TRUE(generator->called_);
> EXPECT_EQ("", generator->parameter_);
> }
>
> At a quick glance it seems like the code tries to access C:.
> In cygwin however the path to C: is /cygdrive/c.
>
> BR / N
>
>
> --
> *From:* Niclas Blomgren
> *Sent:* den 23 oktober 2008 09:50
> *To:* 'Kenton Varda'
> *Cc:* protobuf@googlegroups.com
> *Subject:* RE: Make check reports error
>
> Hi!
>
> Solaris: Yes it was a sparc system. 64-bit.
>
> Cygwin: Ok here it is. I have also attached the entire "make check " in a
> logfile.
>
> [ RUN ] CommandLineInterfaceTest.WindowsOutputPath
> google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
> Value of: return_code_
> Actual: 1
> Expected: 0
> google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
> Value of: error_text_
> Actual: "C:\/: Permission denied
> "
> Expected: ""
> google/protobuf/compiler/command_line_interface_unittest.cc:522: Failure
> Value of: generator->called_
> Actual: false
> Expected: true
> [ FAILED ] CommandLineInterfaceTest.WindowsOutputPath
> [ RUN ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
> google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
> Value of: return_code_
> Actual: 1
> Expected: 0
> google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
> Value of: error_text_
> Actual: "C:\/: Permission denied
> "
> Expected: ""
> google/protobuf/compiler/command_line_interface_unittest.cc:538: Failure
> Value of: generator->called_
> Actual: false
> Expected: true
> google/protobuf/compiler/command_line_interface_unittest.cc:539: Failure
> Value of: generator->parameter_
> Actual: ""
> Expected: "bar"
> [ FAILED ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
>
>
>
> Hopeing you can help me.
> Best Regards / Niclas Blomgren
>
>
> --
> *From:* Kenton Varda [mailto:[EMAIL PROTECTED]
> *Sent:* den 23 oktober 2008 00:19
> *To:* Niclas Blomgren
> *Cc:* protobuf@googlegroups.com
> *Subject:* Re: Make check reports error
>
> On Wed, Oct 22, 2008 at 7:23 AM, Niclas Blomgren <
> [EMAIL PROTECTED]> wrote:
>
>> Solaris:
>>
> I'm guessing this was a sparc system, not x86? Was it 32-bit or 64-bit? I
> think someone else reported the same problem but we were not able to track
> it down.
>
>> Cygwin:
>>
> Can you include the text of the actual failures in your log? (You only
> included the summary.)
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Add .net support
On Oct 23, 12:11 pm, [EMAIL PROTECTED] wrote: > I am a .net developer and I like this protocol buffers , so I want > to extend this to .net framework as well. so I need you help. There are at least 3 projects to support Protocol Buffers in .NET. See http://code.google.com/p/protobuf/wiki/OtherLanguages Jon --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
strings with fixed length
Hi!
I'd like to realize messages which do not need to allocate memory
during runtime. All the allocation should be done
at initialization. Therefor I'd need some mechanism to define strings
with fixed length in .proto files.
I read about the option annotation in version 2.0.2.
Is it possible to change the code generation with this annotations, so
that a string is not created as new std::string
but also reserve the memory which is set in the option:
e.g. in the proto file:
message StaticSizeMsg
{
required string message = 1 [size = 50];
}
The generated code should like like this:
std::string message_;
message_.reserver(50);
thanks,
greets Ralph
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Add .net support
HI Friends, I am a .net developer and I like this protocol buffers , so I want to extend this to .net framework as well. so I need you help. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Any way to dissect ProtBuf serialized data without knowing the structure in advance?
[EMAIL PROTECTED] wrote: > I'm trying to consume data from an app that generates output > serialized via Protocol Buffers but do not have the original spec for > the specific structures that have been encoded. Is there a relatively > straight-forward path to deserializing, or even just decoding, the > serialized data stream without knowing its structure in advance? > There is no straight-forward path. The wire format is not self-describing. You get the outermost field numbers and wire types and data chunks for free. But the numeric wire types do not tell you how to interpret them : signed vs unsigned, double/float vs integer, whether it is zigzag encoded, the byte-size of the field, whether it is an enum (never mind which one). The length-encoded fields are slightly better. If the data chunk parses as a valid message then it is probably a message. If it parses as valid UTF8 then it is probably a string. Otherwise it must be a byte array. If the same sat of field numbers + wire types comes up repeatedly then they may be same message type. Many identical fields in a row are probably for a repeated field, and as such you can assume the contents are the same type. The multiple values gives you a hand in picking how to decode them. For a self-describing binary type you have to look elsewhere (e.g. HDF5). -- Chris --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Where are the pre-compiled lib and supporting header files?
Hi, I would be grateful if someone could point me in the right direction (please see subject) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: Make check reports error
Hi again,
I took a quick look at this code in command_line_interface_unittest.cc
TEST_F(CommandLineInterfaceTest, WindowsOutputPath) {
// Test that the output path can be a Windows-style path.
NullCodeGenerator* generator = RegisterNullGenerator("--test_out");
CreateTempFile("foo.proto",
"syntax = \"proto2\";\n");
Run("protocol_compiler --test_out=C:\\ "
"--proto_path=$tmpdir foo.proto");
ExpectNoErrors();
EXPECT_TRUE(generator->called_);
EXPECT_EQ("", generator->parameter_);
}
At a quick glance it seems like the code tries to access C:.
In cygwin however the path to C: is /cygdrive/c.
BR / N
From: Niclas Blomgren
Sent: den 23 oktober 2008 09:50
To: 'Kenton Varda'
Cc: protobuf@googlegroups.com
Subject: RE: Make check reports error
Hi!
Solaris: Yes it was a sparc system. 64-bit.
Cygwin: Ok here it is. I have also attached the entire "make check " in
a logfile.
[ RUN ] CommandLineInterfaceTest.WindowsOutputPath
google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
Value of: return_code_
Actual: 1
Expected: 0
google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
Value of: error_text_
Actual: "C:\/: Permission denied
"
Expected: ""
google/protobuf/compiler/command_line_interface_unittest.cc:522: Failure
Value of: generator->called_
Actual: false
Expected: true
[ FAILED ] CommandLineInterfaceTest.WindowsOutputPath
[ RUN ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
Value of: return_code_
Actual: 1
Expected: 0
google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
Value of: error_text_
Actual: "C:\/: Permission denied
"
Expected: ""
google/protobuf/compiler/command_line_interface_unittest.cc:538: Failure
Value of: generator->called_
Actual: false
Expected: true
google/protobuf/compiler/command_line_interface_unittest.cc:539: Failure
Value of: generator->parameter_
Actual: ""
Expected: "bar"
[ FAILED ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
Hopeing you can help me.
Best Regards / Niclas Blomgren
From: Kenton Varda [mailto:[EMAIL PROTECTED]
Sent: den 23 oktober 2008 00:19
To: Niclas Blomgren
Cc: protobuf@googlegroups.com
Subject: Re: Make check reports error
On Wed, Oct 22, 2008 at 7:23 AM, Niclas Blomgren
<[EMAIL PROTECTED]> wrote:
Solaris:
I'm guessing this was a sparc system, not x86? Was it 32-bit or 64-bit?
I think someone else reported the same problem but we were not able to
track it down.
Cygwin:
Can you include the text of the actual failures in your log? (You only
included the summary.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: Data structures using protocol buffers
Thanks. I am trying to use protocol buffers with a map reduce
framework to work on large graphs. The graphs are too big to fit in
memory so building auxiliary data structures is difficult. Any ideas?
On Oct 22, 2:48 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
> Protocol Buffers are a serialization format, rather than general-purpose
> data structures. To do computations, you'd probably want to build some
> auxiliary data structures, which you populate when you deserialize the
> protobuf data. You could have node objects that resemble your original
> .proto file, where nodes have references to their neighbors, and you'd
> probably need a map from node id to node object reference, which you'd
> use during deserialization.
>
> --
> Jeremy Leader
> [EMAIL PROTECTED]
>
> GDR wrote:
> > my bad. The code snippet should be as follows:
>
> > for(UndirectedGraphNode node : UndirectedGraph.getNodesList() ) {
> > double sum = 0;
> > int count = 0;
> > for(UndirectedGraphNodeReference neighbor :
> > node.getNeighborsList() ) {
> > sum +=
> > count++;
> > }
> > node.setWeight(sum/count);
>
> > }
>
> > - graph.proto -
>
> > package graph;
>
> > option java_package = "graph";
> > option java_outer_classname = "UndirectedGraphType";
> > option optimize_for = CODE_SIZE;
>
> > message UndirectedGraphNodeReference {
> > required string id = 1;
> > }
>
> > message UndirectedGraphNode {
> > required string id = 1;
> > required double weight = 2;
> > repeated UndirectedGraphNodeReference neighbors = 2;
> > }
>
> > message UndirectedGraph {
> > repeated UndirectedGraphNode nodes = 1;
> > }
>
> > On Oct 22, 2:36 pm, GDR <[EMAIL PROTECTED]> wrote:
> >> That does solve the duplicate information problem but it makes updates
> >> to node attributes (like weight) difficult. Let's say, I want to
> >> assign the weight of each node to the average of its neighbors.
>
> >> for(UndirectedGraphNode node : UndirectedGraph.getNodesList() ) {
> >> double sum = 0;
> >> int count = 0;
> >> for(UndirectedGraphNodeReference neighbor :
> >> node.getNeighborsList() ) {
> >> sum +=
> >> count++;
> >> }
> >> node.setWeight(sum/count);
>
> >> }
>
> >> - graph.proto -
>
> >> package graph;
>
> >> option java_package = "graph";
> >> option java_outer_classname = "UndirectedGraphType";
> >> option optimize_for = CODE_SIZE;
>
> >> message UndirectedGraphNodeReference {
> >> required string id = 1;
> >> required double weight = 2;
>
> >> }
>
> >> message UndirectedGraphNode {
> >> required string id = 1;
> >> repeated UndirectedGraphNodeReference neighbors = 2;
>
> >> }
>
> >> message UndirectedGraph {
> >> repeated UndirectedGraphNode nodes = 1;
>
> >> }
>
> >> On Oct 22, 2:14 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
>
> >>> I was assuming all the properties of a node (weight, label, color,
> >>> whatever) would be in UndirectedGraphNode; UndirectedGraphNodeReference
> >>> would only have the id and nothing else.
> >>> --
> >>> Jeremy Leader
> >>> [EMAIL PROTECTED]
> >>> GDR wrote:
> Thanks Jeremy. That worked!
> But we now have information about the same node being replicated. For
> instance, let's say we have a field 'weight' attached to each node as
> shown below. This setup will replicate the weight information of a
> node as many times as its degree. If the weight of a node changes, I
> will have update all it's occurrences in the PB. Any way I can avoid
> it?
> package graph;
> option java_package = "graph";
> option java_outer_classname = "UndirectedGraphType";
> option optimize_for = CODE_SIZE;
> message UndirectedGraphNodeReference {
> required string id = 1;
> required double weight = 2;
> }
> message UndirectedGraphNode {
> required string id = 1;
> repeated UndirectedGraphNodeReference neighbors = 2;
> }
> message UndirectedGraph {
> repeated UndirectedGraphNode nodes = 1;
> }
> On Oct 21, 6:37 pm, Jeremy Leader <[EMAIL PROTECTED]> wrote:
> > Keep in mind that protobufs describe serialized data, and there's no
> > concept of an object reference like Java uses. In your example, if A
> > and B are neighbors, then in your proto, the data representing A
> > contains the data representing B, and the data representing B contains
> > the data representing A!
> > One way around this is to implement your own form of references, perhaps
> > using the node ids like this:
> > package graph;
> > option java_package = "graph";
> > option java_outer_classname = "UndirectedGraph";
> > option optimize_for = CODE_SIZE;
> > message UndirectedGraphNodeReference {
> > required string id = 0;
> > }
> > message UndirectedGraphNode {
> > required string id = 0;
> > repeated UndirectedGraphNodeReference neighbors;
> > }
> > message UndirectedGra
