Re: Atom and prev links

we dont know when it will work.

On Fri, Jun 28, 2013 at 6:14 PM, Erik Wilde <[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]> 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.
>
>
> 
>
>


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