On Mon, Dec 12, 2011 at 4:53 AM, Robert Collins <robe...@robertcollins.net> wrote: > So, this has come up a few times, how should we do object ids. > > I've got a proposal, which I ran past wallyworld (as a time-zone > friendly person I knew has live-fire SOA experience). > > Remember that SOA object ids are opaque: you cannot depend on their > structure in code. 'foo' is a valid object id, as is 'dr strangelove'. > > However, humans do debugging and inspection of things, and for them we > can choose to be a little nicer. > > The constraints are: > - no two object ids can be the same unless the same object is being > referenced. > - object ids cannot change (unless some explicit process is > undertaken - e.g. messages to all services to update their references) > - object ids must be bounded in length: no 4K strings. > - *only* the service emitting the object needs to be able to > dereference it: there is no 'global' allocation or parsing authority > > I propose the following scheme for our SOA ids: > $service$instance:$type:$typeid > ... > Unless folk can poke holes in this, I will update the SOA docs to > reflect this as the overall approach, and we can see how it goes. >
How would this work with other projects in the Canonical data centre that wanted to talk to a Launchpad service? Would there have to be a registry of service names? What about teams that have different kinds of instances? jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
