Re: Atom and prev links

btw just to add to this. The specification contradicts itself. If I
have to adjust a prev link on the archive ...

How can:

" The requirement that archive documents be stable allows clients to

   safely assume that if they have retrieved one in the past, it will
   not meaningfully change in the future. "

I would tend to read this as immutability.

Is changing a prev link not a meaningful change? I would consider it
very meaningful.

Cheers,

Greg


On Fri, Jun 28, 2013 at 5:45 PM, 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.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/