launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Mon, Dec 12, 2011 at 4:53 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> 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