Hi Geert,
Sorry for taking so long to respond
On Mon, 2010-10-04 at 13:37 +0200, Geert Jansen wrote:
Independent of these three conclusions, there's a complication
that
arises on how to access the root tag. Right now we have short numeric
IDs so it's easy to assign special significance to -1.
To be clear - clients should not assign any special significance to any
IDs. All IDs are completely opaque
But most of the
API assumes hat IDs are opaque identifiers and there seems to be a move
towards the use of those IDs e.g. with the change of cluster IDs from
ints to UUIDs. There's a similar problem with templates. Maybe the API
entry point should contain something like:
<link rel="tags/root" href="tags/xxxxxxxxxxxxxx" />
and <link rel="templates/default"/> right?
In the case of the root tag, I had thought clients would find it either
by finding the tag with no parents or just by looking for name=root
For the default template, name=Default would have special significance
But I think your suggestion makes some sense. We don't want to confuse
things by allowing clients to rely on specific resource names. Instead,
clients should only rely on specific relationship names
I don't think you've filed a trac issue on this yet? Care to do that
now?
Thanks,
Mark.