Re: Atom and prev links

We have considered this empty feed page as well! We were thinking its
slightly more efficient (and understandable) to have a status code but
maybe not (thinking client logic).

If I were to do this again, I might consider using 302 some other
temporary redirect, instead of the 404 or the empty feed; redirect
back to the current (infinitely cacheable) first page.  When a new
item appears, the 302 would turn into the "new" first page" a 200 with
new next/prev links,

I am curious why not a 204. It would seem to be a reasonable fit here
"keep your doc, retry after ..."

Cheers,

Greg

On Fri, Jun 28, 2013 at 7:09 PM, Erik Mogensen <[email protected]> wrote:
>
> On Fri, Jun 28, 2013 at 12:16 PM, Greg Young <[email protected]>
> wrote:
>>
>>
>>
>> We have a mature atom implementation for distribution of event streams
>> and as always the devil is in the details...
>>
>> The issue revolves around prev links. At some point on an atom feed
>> you will hit the current item, prev will point to the next item that
>> does not yet exist. Most implementations I can find 404 this uri and
>> the client has the logic to keep polling the 404. This seems off to
>> me, I would expect this to be a 204. Then if I change my uri structure
>> it becomes a 404, otherwise it would seem that if I change my uri
>> structure all prev uris would need to redirect to the new ones (which
>> would be a rather large undertaking).
>>
>> I couldn't find any details on this in relevant specs, has anyone seen
>> this?
>>
> Greg, I'd just like to explain how we do more or less the same thing.  We
> also use the prev link of the "first page" of a feed to link to the page
> containing the items that "will be".  We find that it's an extremely
> resilient way of dissipating information about things that fit in atom
> feeds, and a relatively efficient system too.
>
> Infinitely cacheable resources are nice, but instead of 404, or 204 and so
> on, we expose an empty feed document, with a next link but no prev link.
> When things happen, the page (when refreshed) contains one or more entries,
> and becomes cacheable.
>
> Our "head" document is very small; contains no real data so it's easy to
> generate; supports cache validation, and if it's incorrectly cached as fresh
> by an intermediary or a caching client, it only impedes the ability of
> clients to advance to the "newer" entries.  Eventually, they will advance to
> the next state.
>
> If I were to do this again, I might consider using 302 some other temporary
> redirect, instead of the 404 or the empty feed; redirect back to the current
> (infinitely cacheable) first page.  When a new item appears, the 302 would
> turn into the "new" first page" a 200 with new next/prev links,
>
> I wonder if "Cache-Control" or "Retry-After" would be useful for 302
> responses, to ask clients to back off under heavy load.
> --
> -mogsie-



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.