On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also do
the job. However this still means that clients need to check the first
fh:prev document if they know all entries there - if my
Am 18.07.2005 um 19:33 schrieb Mark Nottingham:
On 18/07/2005, at 1:29 PM, Stefan Eissing wrote:
I agree that special URIs are not that great either. Another idea
might be nested elements:
stateful feed:
fh:historyfh:prevhttp://example.org/thingie1.1/fh:prev/fh:
history
stateful
Am 18.07.2005 um 18:59 schrieb James M Snell:
Mark Nottingham wrote:
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define
that an empty fh:prev (refering to
Am 18.07.2005 um 23:21 schrieb Mark Nottingham:
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still
Am 21.07.2005 um 16:13 schrieb Mark Nottingham:
On 19/07/2005, at 1:48 AM, Stefan Eissing wrote:
[...]
I have the feeling that clients will need to protect themselves from
servers with almost infinite histories. So a client will probably
offer a XX days into the past, max NN entries
Am 16.08.2005 um 17:42 schrieb Mark Nottingham:
On 16/08/2005, at 1:27 AM, Stefan Eissing wrote:
[...]
Ch. 5 similar: MUST occur unless. If the document is an archive
there are only 2 possiblities: either fh:prev is there or not. If not
it will always terminate the archive list, won't
Am 25.08.2005 um 00:07 schrieb Mark Nottingham:
Just bouncing an idea around; it seems that there's a fair amount of
confusion / fuzziness caused by the term 'stateful'. Would people
prefer the term 'incremental'?
I.e., instead of a stateful feed, it would be an incremental feed;
Am 07.09.2005 um 01:18 schrieb Mark Nottingham:
Feed History -04 is out, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-04.txt
Good! I think it is now easy to understand where the spec applies and
how the different elements interact. I just wish I
Am 14.10.2005 um 20:00 schrieb James Holderness:
Mark Nottingham wrote:
Hmm. Yeah, I see what you're saying. Actually, I think this is an
opportunity -- we we define a new link relation to the subscription
document, and specify that it can only occur in archive documents, it
obviates the
Am 19.10.2005 um 19:12 schrieb Mark Nottingham:
* Reconstructing a feed should use:
a) a specific relation, e.g., prev-archive
+0
b) a generic relation, e.g., previous
+1
Am 23.10.2005 um 23:34 schrieb Mark Nottingham:
On 23/10/2005, at 1:04 PM, Peter Robinson wrote:
I prefer 'subscribe' because it better describes the meaning and
intention behind the link, but I can live with 'current' if that is
the
consensus.
Well, Tim seemed to have a pretty strong -1
Mark, my comments to the document:
- much easier to understand with the split of the 3 use cases
- very nice that archive documents are supposed to be frozen and
fixed (dunno when that changed, but I think it was not so from the
start)
2 minor nitpicks (hey, its me):
- it seems that
Looks fine to me.
Cheers,
Stefan
Am 18.09.2006 um 15:56 schrieb Mark Nottingham:
Feed History is now Feed Paging and Archiving, to reflect what it's
become.
This draft is mostly a cleanup of -06, incorporating all of the
feedback I've seen to date (thanks to all). If I missed
Am 24.10.2006 um 01:07 schrieb Mark Nottingham:
OK. I'm adding this text just after the list of feed types in the
introduction;
---8---
The semantics of a feed that combines these types is undefined by
this specification.
---8---
WRT what future specs can or can't do, that's pretty
14 matches
Mail list logo
