I've actually worked on something like that recently, but tied to a particular use case. I think you'll find it pretty hard to solve the problem in a completely general-purpose way, unless you end up writing a code generator of some sort. In order to hide the UIDs from the app, you will need to have some sort of higher-level versions of all the classes which provide the application-level interface, and which use protocol buffers internally to encode themselves.
On Sat, Aug 15, 2009 at 6:34 PM, Micah <[email protected]> wrote: > > I am working on a system by which to send references to message > objects over the wire and was wondering if anyone has done this > before. I have a few ideas about how to do things but I wanted to get > some input from others before I re-invent the wheel. > > The general idea would be that a server may tell the client about Foo, > a message that references messages Baz and Foz. However, Bar (another > message) also references Baz and Foz. In order to avoid sending the > same Baz and Foz instance multiple times Foo and Bar just contain a > reference to Baz and Foz. The client can then ask the server for Baz > or Foz if it doesn't already have them when it receives a Foo or Bar > message. > > Example flow: > * Server sends Foo to client that references Baz instance #243 and > Foz instance #62. > * Client receives the message and notices that it doesn't know about > Baz #243 or Foz #62. > * Client sends a request to the server asking for Baz #243 and Foz > #62. > * Server receives the request and sends Baz #243 and Foz #62 to the > client. > * Client receives Baz #243 and Foz #62 and caches them and then goes > about processing the Foo message it received earlier (it now has the > full data structure available). > > * Server sends Bar to client that references Baz #645 and Foz #62. > * Client receives the message and finds Foz #62 but not Baz #645 in > it's local cache. > * Client sends a request to the server asking for Baz #645. > * Server receives the request and sends Baz #645 to the client. > * Client receives Baz #645 and caches it and then goes about > processing the Bar message it received earlier. > > * Client sends Foo message to the server that references Baz #645 and > Foz #62. > * Server receives the message and since it already knows about Baz > #645 and Foz #62 it doesn't need to ask the client about them. > > As you can see, the server only had to send one copy of Foz #62 even > though it was referenced in three messages (Foo twice and Bar once). > Ideally this would all be abstracted away from the view of the > application programmer and they would only have to deal with building > messages that contain references and the underlying messaging system > would deal with requesting missing pieces and caching them. > > My initial thought was to just have some int32 UID field on every Baz > and Foz object and then Foo and Bar would contain a similar int32 > field where they wanted to reference the Baz / Foz. However, this > seems like it leaves a lot that can't be abstracted out so the > application programmer has to understand that those int32 fields in > Foo and Bar are references to other objects and they would have to > look them up in the cache every time. This method also makes it > difficult for the messaging system to know it needs to request a > remote reference without fully processing the incoming message. > > I have some other thoughts on how to handle the problem but I haven't > really fleshed them out much yet so input is welcome. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
