Re: Atom and prev links

i guess then there's little to communicate in a link hint (other than a 
very vague "maybe don't try before X"). but if the links are expected to 
work at some predictable time (a daily newsletter, for example), then i 
guess you could you a link hint to inform clients about this.

On 2013-06-28 08:23 , Greg Young wrote:
> we dont know when it will work.
>
> On Fri, Jun 28, 2013 at 6:14 PM, Erik Wilde <[email protected]
> <mailto:[email protected]>> wrote:
>
>     could a link hint help? saying "this will eventually work but don't
>     expect it to work before ..."? cheers, dret.
>
>     On Jun 28, 2013, at 7:45, Greg Young <[email protected]
>     <mailto:[email protected]>> wrote:
>
>>
>>
>>     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] <mailto:[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.
>>
>>
>>     
>
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.

-- 
erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |