On Thu, 2010-09-30 at 07:49 -0400, Itamar Heim wrote:
> -----Original Message-----
> From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api-
> bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin
> Sent: Wednesday, September 29, 2010 18:01 PM
> To: rhevm-api
> Subject: [rhevm-api] Representing the hierarchial nature of tags
>
> Hey,
>
> Latest git contains a pretty complete implementation of tags, except for
> representing the hierarchial nature tags
>
> Here's how the concept works:
>
> - A tag can have child tags
>
> - If any of a childs' tags is applied to an object, then the parent
> tag is also said to apply to the object[1]
>
> - There is a 'root' pseudo-tag that applies to all objects
>
> - The tags namespace is flat - you cannot have a 'bar' tag as a child
> of 'foo' if a 'bar' tag exists elsewhere in the hierarchy
>
> We had a few to consider when deciding how to model this in the REST
> API:
>
> 1) Represent as a flat collection or as a hierarchy of collections
>
> In the former option, we might just have a single tags collection
> where each tag contains a reference to its parent tag
>
> In the latter option, we'd represent child tags as a
> sub-collection of each tag
>
> 2) Use <link rel="parent"/> or <parent><tag
id="..."/></parent> to
> reference a tags parent tag
>
> 3) Whether to represent the concept of the root tag as an actual
> visible tag or just have make children of the root tag have no
> parent in their representation
>
> The crux of the issue turns out to be how best to represent using PUT to
> move a tag around in the hierarchy.
>
> i.e. you have a tag 'bar' (id=8) under tag 'foo' (id=0) and you want
to
> move 'foo' under the root tag (id=-1):
>
> 1) If we went with a hierarchy of collections, then the PUT request
> would look like this:
>
> PUT /tags/-1/tags/0/tags/8 HTTP/1.1
> Accept: application/xml
> Content-Type: application/xml
>
> <tag>
> <parent><tag id="-1"/></parent>
> </tag>
>
> HTTP/1.1 200 OK
> Content-Type: application/xml
>
> <tag id="8" href="tags/-1/tags/8">
> <name>foo</name>
> <description></description>
> <parent>
> <tag id="-1" href="tags/-1"/>
> </parent>
> </tag>
>
> What I really don't like is that the PUT causes the URI of the tag
> to change. I guess we could use 'HTTP/1.1 301 Moved Permanently',
> but ... ick.
>
> Also, the URI structure is pretty disgusting.
>
> 2) If we used <link rel="parent"/> an update would look like:
>
> PUT /tags/8 HTTP/1.1
> Accept: application/xml
> Content-Type: application/xml
>
> <tag>
> <link rel="parent" href="tags/-1"/>
> </tag>
>
> HTTP/1.1 200 OK
> Content-Type: application/xml
>
> <tag id="8" href="tags/8">
> <name>foo</name>
> <description></description>
> <link rel="parent" href="tags/-1"/>
> </tag>
>
> The problem here is that we don't allow updating a <link/> anywhere
> else in the UI. Links are more for navigation rather than mutable
> data.
>
> 3) If we didn't have an explicit resource representing the root tag,
> the update would look like:
>
> PUT /tags/8 HTTP/1.1
> Accept: application/xml
> Content-Type: application/xml
>
> <tag>
> <parent><tag/></parent>
> </tag>
>
> HTTP/1.1 200 OK
> Content-Type: application/xml
>
> <tag id="8" href="tags/8">
> <name>foo</name>
> <description></description>
> </tag>
>
> That's not too bad, but I think it works better if you explicitly
> reference the root tag.
>
> After all that, the conclusion is to have a flat collection, use a
> <parent/> element and have an explicit root resource. The update then
> looks like:
>
> PUT /tags/8 HTTP/1.1
> Accept: application/xml
> Content-Type: application/xml
>
> <tag>
> <parent><tag id="-1"/></parent>
> </tag>
>
> HTTP/1.1 200 OK
> Content-Type: application/xml
>
> <tag id="8" href="tags/8">
> <name>foo</name>
> <description></description>
> <parent>
> <tag id="-1" href="tags/-1"/>
> </parent>
> </tag>
>
>
> Thoughts?
>
> Cheers,
> Mark.
>
> [1] - this seemed a bit backwards to me at first. I had assumed the
> semantics to be that if a parent tag applies to an object, all child
> tags also apply to the object. i.e. tags are more about what groups an
> object is a member of rather than what groups an object is visible to
>
...
[IH] Two thoughts on this:
1. moving tags around is not currently supported.
The Move-Tag powershell command isn't supported?
2. we will probably allow tags with same name in different places in
the
hierarchy at some point in the future. So maybe tag URIs should be viewed
as folders in the OS - via their full path, and 'not found' error if/when
we will support moving tags, since the path would no longer be correct.
Yes, see (1) above where I discuss what the might look like. Not
pleasant.
It strikes me that tags hierarchy isn't all that interesting. If we
didn't have an explicit hierarchy, users could achieve the same effect
by encoding a hierarchy in tag names.
e.g. instead of "rhevm" as a explicit subtag of "development", you
could
add a "development.rhevm" tag and search for "tag=development*"
Indeed, the screenshots in the docs show something very similar:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization_for_S...
Cheers,
Mark.