Re: Atom and prev links

not predictable (its an event stream) it could be 1ms or 30 days.

we have switched to archive-prev (our stream is complete and
non-lossy) but it really feels like an immutable prev/next is needed
to be standardized.

we figured a 204 "don't change your document" + retry fit the bill.
maybe not ...

As of now there is no good way to do what we do (non-lossy stream)
under 5005. As such we will have to just do something I guess and then
try to get a spec change. The changes are not huge and I think are in
the spirit of the spec (weird how they want mutability and
immutability at the same time).

Greg

On Fri, Jun 28, 2013 at 6:44 PM, Erik Wilde <[email protected]> wrote:
> 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 |



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