launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 12 December 2011 04:53, Robert Collins wrote:
[...]
> I propose the following scheme for our SOA ids:
> $service$instance:$type:$typeid

Seems good, though it reminds me of namespaced-OOPS hell, unfairly
perhaps. Do we need to include $service?

> Where service is one of ('lp', 'oops-tools', 'sso') today, with more
> services allocated as we bring up additional microservices.
> $instance is one of ('', '-qastaging', '-staging') and is used to
> deal with collisions with objects created on staging services. It
> also allows us to consume both a production and a staging service
> from a staging service, if we want to. (And we will, for the
> librarian, eventually).

Using -staging to namespace staging, for example, is confusing with
regards to service names like oops-tools. A different delimiter
between service and instance like "/" or "." would be unambiguous.

> $type is allocated within the service itself. Examples are 'person',
> 'archive' etc. Types that are exported, basically.  $typeid is any
> string value that the service wants to use to get back to the
> original object. For instance, a UUID, or a row id, or a pg object
> id would all be valid. For things where no-guessability matters,
> using a UUID is appropriate, for other things using the DB primary
> key is fine, as long as it meets the stability and uniqueness
> constraints.

What constraints will there be on each part of the ID, or am I jumping
the gun? I would imagine something like a strict subset of printable
ASCII would make sense, but perhaps there are arguments for having
wider options. I strongly feel we should avoid encoding (or escaping)
issues; sticking with ASCII is probably a good way of doing that.

> As an example - 'lp:person:2' - would be able to be passed around to
> multiple services (team membership, audit trail, notification
> service). Only LP itself could interpret the string however to mean
> Person 2.

Using the lp: prefix in particular may cause confusion between objects
and bzr URLs. For greppability (and linkability) it might be worth
using a common prefix like "obj" or just "o":

  obj:lp:person:1234

> 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.

Is there value in adopting URNs [1] for the basic structure and rules
of these IDs? There may already be some tool support for dealing with
these, though I've never knowingly stumbled upon any.

Also, do we want to make objects externally referencable? I'm thinking
of being able to use, say, an HTTP URL that contains an object ID.
That would impact the IDs constraints.

Gavin.


[1] http://tools.ietf.org/html/rfc2141