[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AtomPub Media Repository




On Feb 10, 2010, at 8:53 AM, Asbjørn Ulsberg wrote:

> 2010/2/8 Asbjørn Ulsberg <list@xxxxxxxxxxxxxxxxxx>
> 
> So, I'm thinking the URIs would look a little something like this:
> 
> http://example.com/
> http://example.com/acme/
> http://example.com/acme/templates/
> 
> http://example.com/acme/photos/
> http://example.com/acme/photos/chrome/
> http://example.com/acme/photos/products/
> http://example.com/acme/photos/illustrations/
> 
> Hm. From what I can tell by RFC 5023, I can have:
> 
> 1. Only one level of work spaces on the web sites. These can't be nested.
> 2. Only one level of collections within each work space. These can't be nested.
> 3. As many levels of categories I want through altering "scheme" values, like so:
> 
> <categories fixed="no">
>   <atom:category scheme="http://example.org/acme/photos/"; term="chrome" />
>   <atom:category scheme="http://example.org/acme/photos/"; term="products" />
>   <atom:category scheme="http://example.org/acme/photos/products/"; term="hats" />
>   <atom:category scheme="http://example.org/acme/photos/products/"; term="mittens" />
>   <atom:category scheme="http://example.org/acme/photos/"; term="illustrations" />
> </categories>
> 
> Is this perfectly fine? As far as I can tell, this allows for an extensible category tree that can be freely manipulated by the client.

Yep.

> The only challenge I can see is how to manage existing categories; renaming, deleting, etc.,

Make resources that have the proper semantics, maybe make categories entries themselves and manage like any other item

PUT /categories/vehicles/cars/japanese-cars/title
Content-Type: text/plain

[New title]

303 See Other
Location: /categories/vehicles/cars/japanese-cars

[full new category representation]



> as well as moving entries from one category to another.

POST them to the collection that they should be in or delete their member entries. Note that collection member can be a different resource than the resource that is a member.

> 
> I've thought about tackling each of these like so:
> 
> - Moving entries from one category to another: PUT the entry with the new atom:category element in it, effectively removing the association with the old category.

Might also be ok, yes.

> - Deleting a category: Move all entries out of the category, effectively making the category void which can implicitly be translated to "deleted" by the server.

Yes, possible

> - Renaming a category: Say the old is called "hats" and should be renamed to "headwear", you would create the "headwear" category, then move all entries from "hats" to "headwear".

That is not a renaming but a move. Do not put soomething that might change (e.g. cat title) into the URI. Only use key-like attributes.

> 
> That seems to solve all obstacles I can see, but the question is: is this kosher per RFC 5023? I can see a problem in the rename/moving algorithm if a category contains a large amount of entries as you would need to PUT each individual entry, which could take a lot of time.

Yes. Renaming the category should really be an update of the corresponding resource itself.

Jan


> 
> -- 
> Asbjørn Ulsberg           -=|=-        asbjorn@xxxxxxxxxx
> «He's a loathsome offensive brute, yet I can't look away»

-----------------------------------
 Jan Algermissen, Consultant
 NORD Software Consulting

 Mail: algermissen@xxxxxxx
 Blog: http://www.nordsc.com/blog/
 Work: http://www.nordsc.com/
-----------------------------------