For Connections 2.0, we're enabling the management of blog instances
using atompub. In our service document, there will be a separate
workspace with a single collection, each member entry represents a blog
owned by the authenticated user.
This is also the model we've been using with GData; an AtomPub
collection where each entry represents a collection, possibly with
read/write attributes the represent the collection properties. You can POST to create new collections, or PUT/DELETE to the member resources to edit collection attributes or remove them. We've
been informally calling these 'meta-feeds' (i.e. feeds of feeds)
although in a publishing context maybe 'meta-collections' would be more
apropos.
for instance,
<entry>
<id>...</id>
<title>blog title</title>
<content>blog description</content>
<updated>...</updated>
<author><name>james</name></author>
</entry>
I'd suggest minor revisions to the above syntax. In particular, I think it's useful to use the Atom out-of-line content syntax to point directly to the blog and an atom:summary element to contain the description. So tweaking the previous example, you'd have:
<entry>
<id>...</id>
<title>blog title</title>
<summary>blog description</summary>
<content type='application/atom+xml; type=feed' src=""
http://myblog.blogspot.com/feeds/techblog' >
<updated>...</updated>
<author><name>james</name></author>
</entry>
The benefit of this is syntax is that you can easily traverse from the blog metacollection to the blog by just following the content src attribute. Otherwise, you have to (somehow) correlate the entry in the meta-collection back to a service document to figure out where it resides.
IMO, this syntax also makes sense from a semantic perspective since the 'content' of the meta-entry is really the referenced blog collection, and the meta-entry is just the metadata for that blog.
In the initial post, the id, updated and author elements are ignored.
We replace those values with server generated values.
The title and content elements provide the name and short text
description of the blog.
With the modified syntax above, the summary would have the short description and content (if any) would be ignored and replaced with a server-generated value.
Once created, a new workspace is added to the service document. each
workspace represents one blog. Each workspace/blog exposes several
collections (entries, media, comments, etc).
Think about the initial POST-to-create-a-blog scenario; it doesn't seem like you'd want
to have to go back to analyze the service document to figure out where
the blog collection you just created resides. Although you still can do this, it is no longer required to do this. That is one of the key motivations for including the collection uri of the created collection inside the meta-entry content.
Cheers!
-- Kyle
There are a few additional things we do to manage access control and
advanced blog settings but those aren't really important here.
- James
Tim Bray wrote:
>
> I'm turning back to mod_atom after ignoring it for a couple of months.
> One of the problems is that you create a blog by adding a line to the
> Apache config file. One config-file line, one publication, nice and
> simple. This doesn't scale if you want to create/destroy pubs much at
> all. So I've been wondering how you'd go about allowing people to
> create publications without screwing with config files. The answer is
> obvious: you have one service doc and collection, where the entries
> represent the publications, with links to the service docs. Then you
> can create and delete publications and update their metadata via the
> Atom Protocol with POST/PUT/DELETE to the "meta-service" doc and the
> links in the "meta-collection" doc.
>
> Interesting question: to create a new publication, do you need to post
> an Entry with <content type="application/atomsvc+xml">? I don't think
> so...
>
> Anyhow... is that all one needs to say? Or are there some other things
> to be worked out that might benefit from standardization? I'll have a
> more informed opinion after I finish implementing.
>
> It occurs to me that having a <link rel="meta-service" href="" of
> meta-service doc" /> might be nice. But I don't need one so maybe YAGNI.
>
> -Tim
>
>