Object paths naming conventions?

[Havoc Pennington]

Hi,

On Fri, Jul 18, 2008 at 12:38 PM, Marcel Holtmann <marcel at holtmann.org> wrote:
> My point is that the actual meaning (name) of the object path is
> irrelevant and it is not needed to tie this to the interface/API
> contract. And thus the namespacing of object paths becomes irrelevant.

It depends. If a spec says "the singleton is at /foo/bar" then it's in
the API contract. If the spec says "call method xyz to get the object
path," then yes a spec like that allows you to generate an object path
on the fly and return it (and also requires an extra round trip, which
is the tradeoff).

But even if you generate object paths on the fly, you should use a
scheme that avoids collisions. You can use a mktemp-like scheme of
generating random strings, or namespacing, or whatever. It won't work
or make sense to generate "/" as the name of every object.

Anyway, you're right the object path is just an arbitrary string and
can be anything; but, it needs to be a unique string for each distinct
object. So that means either random/guid type strings (like mktemp or
uuid), or namespaced strings, or guids inside a namespace is another
common pattern (like /org/foo/{guid}).

Havoc