Subject: feed id's and paged/archive feeds

From: James M Snell <[email-masked]>
Date: Fri, 03 Nov 2006 13:37:37 -0800

Mark,

I cannot recall if I've asked you this in the past but... if I have a
set of paged/archive feed documents all of which make up a single
logical feed, do the atom:id's for each feed document have be the same?
 If not, how do I determine the atom:id of the logical feed?

- James

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Nov 2006 13:25:44 -0800

Sorry, this got lost in my inbox...

I think they do, although the draft is silent on it. This is one of  
those areas where it would have been really nice if the WG had agreed  
to take on FH as part of the core, rather than extension; there are  
lots of little ambiguities like this as a result.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Sun, 26 Nov 2006 20:15:52 -0800

Mark Nottingham wrote:
> [snip]
> I think they do, although the draft is silent on it.
> [snip]

Good enough for me.

Also, the latest draft looks good to me. Ship it!

Thanks Mark.

- James

---

From: Ernest Prabhakar <[email-masked]>
Date: Mon, 27 Nov 2006 11:06:54 -0800

Hi Mark,

Given all the ambiguities, are there any implementations available to  
test against in practice?  Or even implementors planning to make the  
attempt?

- Ernie P.

On Nov 26, 2006, at 1:25 PM, Mark Nottingham wrote:

> those areas where it would have been really nice if the WG had  
> agreed to take on FH as part of the core, rather than extension;  
> there are lots of little ambiguities like this as a result.
>
> Cheers,
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Nov 2006 11:18:34 -0800

Well, since you ask a leading question...

I have a demo implementation of a client at:
  http://www.mnot.net/rss/history/
and my blog does the server side:
  http://www.mnot.net/blog/index.atom

James Holderness has mentioned an implementation, and the Apache  
abdera people seem to be planning something, based on their  
repository. I know of other folks who are planning to integrate into  
products and services, but I can't disclose anything more (I'd  
encourage them to, of course). Anybody else?

The issue we're discussing here, though, isn't about ambiguities in  
*this* spec, but rather in Atom itself; i.e., what does a feed ID  
really identify?

Cheers,

On 2006/11/27, at 11:06 AM, Ernest Prabhakar wrote:

> Hi Mark,
>
> Given all the ambiguities, are there any implementations available  
> to test against in practice?  Or even implementors planning to make  
> the attempt?
>
> - Ernie P.
>
>> I think they do, although the draft is silent on it. This is one  
>> of those areas where it would have been really nice if the WG had

---

From: "James Holderness" <[email-masked]>
Date: Mon, 27 Nov 2006 20:39:23 -0000

Mark Nottingham wrote:
> James Holderness has mentioned an implementation

Snarfer added support for feed history a while back, so it doesn't recognise 
the new archive link relations that were added in recent versions. We 
probably will consider supporting them in a future release if there is 
significant adoption on the server side, but so far most of the major 
implementations I've encountered have been using one of the older 
variations, so we haven't had any incentive to change things yet.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Mon, 27 Nov 2006 13:03:30 -0800

Abdera has basic support for the extension elements and the paging links
(including prev-archive and next-archive).  It does not yet include an
implementation of the feed reconstruction algorithm but will shortly.
The implementation is part of the optional extensions module.

- James

Mark Nottingham wrote:
> James Holderness has mentioned an implementation, and the Apache abdera
> people seem to be planning something, based on their repository. I know
> of other folks who are planning to integrate into products and services,
> but I can't disclose anything more (I'd encourage them to, of course).
> Anybody else?
> 
> *this* spec, but rather in Atom itself; i.e., what does a feed ID really
> identify?
> 
> Cheers,
> [snip]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Nov 2006 13:12:26 -0800

Also, the MediaRSS module references it as a best practice.

When I started working on it, there was interest from server-side  
folks as well (e.g., Six Apart); AFAIK they're just waiting for it to  
be finalised (it's taken a while).

Cheers,

On 2006/11/27, at 11:18 AM, Mark Nottingham wrote:

> repository. I know of other folks who are planning to integrate  
> into products and services, but I can't disclose anything more (I'd  
>> to test against in practice?  Or even implementors planning to  
>> make the attempt?
>>
>> - Ernie P.
>>

---

From: Bill de hOra <[email-masked]>
Date: Tue, 28 Nov 2006 19:55:46 +0000

Mark Nottingham wrote:
> those areas where it would have been really nice if the WG had agreed to 
> take on FH as part of the core, rather than extension; there are lots of 
> little ambiguities like this as a result.

I doubt that would clear things up. This is a HTTP thing, not an Atom 
thing. My thinking on this matter is that Atom feeds aren't resources, 
they're representations. Specifically they're a hack/optimisation to 
deal model collections/iterators for HTTP. Anyone who really cares 
should try sending Atom over XMPP or email; it'll be clear enough that 
entrys matter, but feeds don't.

[An RDF modelling execise by the WG would have made it clear that feeds 
are problematic entities, but we'd probably be going into last call 
sometime the new year as a result.]

cheers
Bill