Re: Atom and prev links

We could do all over prev next even with no archiving. Every uri we create
is immutable. Spec defines additional logic needed for prev/next which is
unneeded for us so archive gives us a simpler client API (also explicit
that we are non lossy)

On Friday, June 28, 2013, Ben Niven-Jenkins wrote:

>
>
> On 28 Jun 2013, at 18:32, Greg Young <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>>
> wrote:
>
> Our whole feed is nonlossy and immutable.
>
>
> Can you expand on what you mean by this. Feed archiving doesn't lose
> information and doesn't require changes to a page once it is first
> generated.
>
> Or do you mean the client cannot handle the content of the URI that
> represents the entry point into the feed changing and expects the content
> of that URI to stay always constant so the clients needs to page "forward
> in time" to find the latest entries?
>
> Ben
>
>
> On Friday, June 28, 2013, Ben Niven-Jenkins wrote:
>
>>
>>
>> On 28 Jun 2013, at 11:16, Greg Young <[email protected]> wrote:
>>
>> > We have a mature atom implementation for distribution of event streams
>> > and as always the devil is in the details...
>> >
>> > The issue revolves around prev links. At some point on an atom feed
>> > you will hit the current item, prev will point to the next item that
>> > does not yet exist.
>>
>> Why not use feed paging and use prev-archive to indicate the previous
>> page and keep your "main" feed as the current page.
>>
>> Client just polls the current page and if it needs to go further back in
>> time it follows prev-archive links until it finds what it wants.
>>
>> You then avoid the problem of links to things that don't exist or
>> updating already archived pages.
>>
>> Ben
>
>
>
> --
> 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.