Re: Atom and prev links

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]> 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]> 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.
> 
> 
>