Re: Atom and prev links

And doing it your way requires every uri we create to be put out twice
(once as mutable and uncachable once as immutable and infinitely cachable).

Take archives. My current archive is therefor mutable. I have to rewrite
the archive every time I add a new one. This sounds like a fairly
complicated protocol as opposed to pre-writing what the next uri will be
and giving some sort of status when it is not yet in existence. This
becomes even more so if my archives are say monthly and widely distributed.
This is especially true for us as our data is already immutable (prev/next
were actually the wrong choice, we should be using archive)

Your client just has to say "more stuff will appear here" and don't move
off my current document until it does (sounds a lot like a 204).

The server just puts out the archives as needed. No playing with etags or
mutability (every uri is always infinitely cachable).

The protocol makes even more sense when you consider dropping long polling
on top of it (get me this thing that may or may not exist).

Cheers,

Greg

On Fri, Jun 28, 2013 at 5:32 PM, Markus Lanthaler
<[email protected]>wrote:

> **
>
>
> On Friday, June 28, 2013 3:19 PM, Greg Young wrote
>
> > btw in doing some research it would appear that RFC 5005 allows
> > for either in the areas where reading of feeds is actually discussed.
> >
> > This process
> > should be repeated recursively until the client encounters a prev-
> > archive link relation that has been processed (the end of the archive
> > is indicated by a missing prev-archive link relation) or an error is
> > encountered.
> >
> > prev/next reading is not discussed but would seem logical to work in the
> > same way. I am unsure why it would be "broken" as you say to return an
> > error. Can link me to the relevant specification?
>
> I didn't say that a spec prohibits it, how could it? You have to expect
> broken links everywhere. I just said I would assume that your
> implementation
> is broken because it creates links that lead to a 404.
>
> Errors shouldn't control the *normal* control flow, they should be
> exceptions.
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>  
>



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