Thanks for the replies so far. To explain a little more what I need all this for probably gives a better overview:
Basically I want to write a framework for mobile devices (Android,iPhone,...) to easily enable data exchange between a device and some server component(s). On top of this framework one could implement ones business logic/application without worrying about how data actually gets from the server to the device. So part of the whole idea is that only parts of the total "object world" would be physically present on the device. I though I could use protobuf for the underlying data transfer method as it's platform independent, light and fast. So I dont want to just model graphs as such but rather arbitrary dependency/attribute relations between objects. That's what I need references for and that's why a complete lookup table wont do for me... @Marc: I dont think that the unique ideas will be a problem in my case as the server could enforce uniqueness. You concerns about the cache may be right - that's one of the things be I will be researching (context aware/probabilistic prefetching) Interop isn't really an issue for me ether: all clients will be known and "in control" anyway... On Dec 8, 6:58 pm, Adam Vartanian <[email protected]> wrote: > > A standard protocol buffer message type ptr_B from which a "flat" Java > > class will be generated does not seem adequat to to so. > > Instead some new abstract Class "RefMessage<T extends Message>" with a > > method "<T> getReferencedObject()" would be the solution. ptr_X > > messages simply had to be transformed to Java classes extending this > > superclass. > > > My questions so far: > > I could write my own code generator for that purpose, right? > > Has anybody tried to implement some similar techniques for reference > > types on top of protocol buffer? > > Is there a completely different approach for this "problem"? > > Am i getting the design and purpose of protobuf wrong when I need/want > > such a solution? > > When I've seen a similar thing done, it's generally been done like this: > > message A { > required int32 ownvalue = 1; > required int32 bref = 2; > > } > > message B { > required int32 othervalue = 1; > > } > > message Overall { > repeated B b = 1; > repeated A a = 2; > > } > > And then you do > > Overall overall; > A a; > B b = overall.getB(a.getBref()); > > Basically, you first send a lookup table, then you send the remaining > items, with references as indexes into the table. To serialize a > graph using that technique, you could send a list of nodes and then a > list of edges. I don't know that it's the best way of doing it, but > it's worked out well where I've seen it. > > - Adam -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. 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.
