RE: Approach to atompub implementation for a forum

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Ivan Sagalaev wrote:
> I'm playing with an idea of implementing AtomPub for my forum 
> and I'm a bit stuck choosing a right architecture. The forum 
> site contains several forums which contain topics which 
> contain articles -- a simple hierarchy.
> 
> First I figured out that individual forums should probably be 
> Collections in AtomPub terms. But as far as I understand a 
> Collection can contain only Entries which themselves cannot 
> be Collections (right?). So then I stuck how to describe 
> topics in forums and, further, articles in topics.

Clearly, each article should be represented as an atom entry. If you have threaded conversations, then each article will have a reference to the article it is replying to (using the atom threading extension), except for the first article in each topic. If you don't have threaded conversations, then they can be considered a reply to the first article in the topic.

Subscription feeds: Each forum can be represented as an Atom feed, where each entry in the feed represents a distinct topic. This allows users to subscribe to each forum to see new threads as they are added. Or, each forum can be represented as an Atom feed, where each entry in the feed is a message, and the topic list is derived by extracting all the articles that do not have a "thr:in-reply-to" element. This allows users to subscribe to an entire forum at once. You might have a per-topic feed, that allows users to subscribe to replies in a thread. Or, you can have a mixture of these kinds of feeds, or none of these feeds. 

AtomPub collections: In order to start a new topic using this design, each forum needs its own AtomPub collection to post to. These would be listed in the service document.

To reply to an topic or article, there needs to be some kind of link from each topic or article to an AtomPub collection, so that the client knows what collection to post the reply to. Currently, there is no standard way of discovering this. If the client can discover that the entry belongs to some collection, then it could just try posting the reply to the same collection, using an thr:in-reply-to element that refers to the original message. I can give you some heuristics to use for this, but in general, there is no standardized mechanism that says "You want to reply to message X? Okay, post your reply to collection Y." IMO, the best solution would be to coin a "reply" link relation that is defined to point to an AtomPub collection.

> Another approach is to represent topics as Collections of articles. 
> Forums can be Workspaces containing topics. But then I have 
> an ever-growing Service document that would describe 
> topics-Collections.

These approaches are not mutually exclusive. A topic can be a collection, an entry, and a feed at the same time. However, you are likely to run into performance problems if you allow users to subscribe to per-topic feeds. Imagine you have 1000 who each subscribe to one new topic each day. Their client is set to update each feed every hour. After the first year, you will be doing 100-requests-per-second just to handle clients subscribed to out-of-date topics. Users are likely to set the refresh interval closer to 1 minute for a forum, so you are looking at about 5,000 requests per second after a year. On the other hand, if you have only per-forum feeds, users will be using up a lot more bandwidth than necessary since they are downloading (many) articles from topics that they aren't even interested in

An alternative would be to give each user a single "subscribe" collection and a "subscribed" feed. The user can post an entry to the collection that looks like this:

   <entry>
       ...
       <link rel='alternate' href='{IRI of the topic}'/>
       ...
   </entry>

The effect would be that all articles in the linked-to topic would show up in the "subscribed" feed. When the user wants to stop subscribing to the topic, it simply deletes the linking entry from the "subscribe" collection.

- Brian