Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
On 20/07/2005, at 10:44 AM, Thomas Broyer wrote: I was actually wondering why non-stateful feeds couldn't have archives: in the This month's Top 10 records feed, why couldn't I link to Last month's Top 10 records? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the 3. in feed-history, no matter how) If we want to solve this issue using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? My main use case for it was to advise aggregators that currently keep state by default (without being about to walk backwards) that this isn't appropriate for some feeds. E.g., NetNewsWire, Shrook and many other aggregators all automatically remember a feed's past entries that it's seen; sometimes, this is undesirable. Maybe that's biting off too much at once... Hmm, that seems awfully complex (and hard to grasp -- but maybe it's just me :) just to avoid a round trip. One, or a few more... depending on how you archive your entries (daily archive document, weekly archive document, N entries per archive document, etc.), how you publish your entries in the subscription feed (N entries in the feed, or only those entries published during the N last days), and who frequently you post. Your subscription feed entries can overlap several archive feeds and the fh:prev jump from archive2.atom to archive5.atom. Using updated, you can avoid 3 round trips in that case. ...or too many: what if I switch URL addressing scheme (e.g. from archive1.atom...archiveN.atom to 2005/January.atom...2005/June.atom)? A dumb reader will retrieve back every archive feed, as it has never ever dereferenced the URIs. Well, if you change your archive scheme, you may change other things too; without more trust between the client and publisher, it probably *should* go back and fetch everything. This is where client-side throttling (as discussed before; e.g., do you really want to go back that far?) would come into effect. There are subtle issues introduced when you do time-based comparison across a network; synchronisation between clocks come into play, and it gets tricky, if not impossible, to specify correct behaviour. Couldn't much the same effect be achieved by saying that implementations can use other mechanisms (e.g., updated in the archive itself, the id in the archive) to ascertain whether it's seen something before? You'd still have one extra fetch, but that's not nearly as big a deal as walking back the entire feed (which I agree would be a problem). Cheers, -- Mark Nottingham http://www.mnot.net/
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Antone Roundy wrote: On Wednesday, July 20, 2005, at 11:44 AM, Thomas Broyer wrote: I was actually wondering why non-stateful feeds couldn't have archives: in the This month's Top 10 records feed, why couldn't I link to Last month's Top 10 records? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the 3. in feed-history, no matter how) If we want to solve this issue using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? I would think that rather than fh:stateful=true | false, it might be more useful to have (with a different element name, and perhaps different values) fh:what-kind-of-feed-is-this=sliding-window | snapshot | ???. If it's a sliding-window feed, fh:prev points to the previous sliding window. If it's a snapshot feed, then fh:prev points to the previous snapshot. fh:what-kind-of-feed-is-this might have a default value of sliding-window. +1 and with the addition of fh:prev/@updated (and an optional fh:prev/@title, see below), it turns feed-history to a really cool extension! We could also add some more hints about fh:prev processing depending on fh:what-kind-of-feed-is-this: * if the value is sliding-window, an Atom Processor MAY reconstruct the feed state automatically without user interaction * if the value is snapshot, an Atom Processor SHOULD NOT retrieve archive snapshot feeds unless told by the user (e.g. showing a link or button using fh:prev/@title as the label); when presented to the user, entries in the retrieved snapshot feed SHOULD replace any entry from within another snapshot (e.g. Last Month's Top 10 records should replace This Month's Top 10 records). fh:prev/@title could be used on sliding-window feeds to indicate the title of the latest entry in the previous feed (just like blog homepages sometimes link to the previous entry using its title). fh:prev would look like: fh:prev updated=2005-06-30T23:55:30 title=Last Month's Top 10 records http://example.net/archives/june.atom/fh:prev -- Thomas Broyer
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
This mail has been around in my drafts folder for about 10 days, but here it is... I'm not sure what my position is wrt what I wrote below... Mark Nottingham wrote: On 04/07/2005, at 6:18 PM, Thomas Broyer wrote: With the -01 draft (it might have been the same within the -00 one too), one can't reuse the process to link to archives of Top Twenty Records or Most Popular Items (e.g. a monthly Top Twenty Records linking to the previous-month Top), because of the a subscription document whose fh:stateful element contains false MUST NOT contain a fh:prev element. Why not just stating that if fh:stateful is false then the prev- linked archive feed doesn't not contain a subset of the previous entries but rather does contain the previous state of the subscription feed. I.e. the meaning of the fh:prev link depends on the value of fh:stateful. That's interesting, but it somewhat changes the semantics of prev; it goes from where you can find previous entries in a logical feed to where you can find an older archive of entries. While these are often the same thing, it might not always be the case; i.e., someone might want to publish a non-time-based feed. So, I'm nervous about having two different semantics for one element, depending upon its context of use. I fully understand (that's actually also somehow bothering me). I was actually wondering why non-stateful feeds couldn't have archives: in the This month's Top 10 records feed, why couldn't I link to Last month's Top 10 records? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the 3. in feed-history, no matter how) If we want to solve this issue using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? I also repeat my proposal for an identifier different from an URI for a reader/aggregator to know whether it has already retrieved an archive document, e.g. using the updated date-time of the fh:prev-linked archive feed. Example: ?xml version=1.0 encoding=utf-8? feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-09; xmlns:history=[TBD] titleExample Feed/title link href=http://example.org// updated2003-12-13T18:30:02Z/updated author nameJohn Doe/name /author idurn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6/id history:statefultrue/history:stateful !-- added an updated attribute with tha atom:updated value of the http://example.org/2003/11/index.atom document. -- history:prev updated=2003-11-24T12:00:00Z http://example.org/2003/11/index.atom/history:prev entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/robots_here/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated summarySome text in a new, fresh entry./summary /entry /feed If I retrieved the feed between 2003-11-24T12:00:00Z and 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http:// example.org/2003/10/index.atom (october, not november). However, I didn't miss any entry. Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry and that I then don't need to dereference http://example.org/ 2003/11/index.atom (november, the new fh:prev URI) Hmm, that seems awfully complex (and hard to grasp -- but maybe it's just me :) just to avoid a round trip. One, or a few more... depending on how you archive your entries (daily archive document, weekly archive document, N entries per archive document, etc.), how you publish your entries in the subscription feed (N entries in the feed, or only those entries published during the N last days), and who frequently you post. Your subscription feed entries can overlap several archive feeds and the fh:prev jump from archive2.atom to archive5.atom. Using updated, you can avoid 3 round trips in that case. ...or too many: what if I switch URL addressing scheme (e.g. from archive1.atom...archiveN.atom to 2005/January.atom...2005/June.atom)? A dumb reader will retrieve back every archive feed, as it has never ever dereferenced the URIs. That 'probably' is also worrying me. I used probably because you
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
On Wednesday, July 20, 2005, at 11:44 AM, Thomas Broyer wrote: I was actually wondering why non-stateful feeds couldn't have archives: in the This month's Top 10 records feed, why couldn't I link to Last month's Top 10 records? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the 3. in feed-history, no matter how) If we want to solve this issue using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? I would think that rather than fh:stateful=true | false, it might be more useful to have (with a different element name, and perhaps different values) fh:what-kind-of-feed-is-this=sliding-window | snapshot | ???. If it's a sliding-window feed, fh:prev points to the previous sliding window. If it's a snapshot feed, then fh:prev points to the previous snapshot. fh:what-kind-of-feed-is-this might have a default value of sliding-window.
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Mark Nottingham wrote: On 04/07/2005, at 6:18 PM, Thomas Broyer wrote: Really good work! Thanks! Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, true and false. I did it this way because I'm not a huge XML Schema fan :) At this point, stateful is effectively xs:boolean with a constraint on the lexical space. I'm not against changing it to '1 or true / 0 or false, except that this makes the spec more verbose (but that's a pretty minor concern, properly managed). What do others think (in either direction)? 1. I don't want to have to link to an XSD library in my XML toolchain just to process true/false in an attribute. 2. I don't want to hack some code together to recognize a single XSD primitive just because I don't want to link to an XSD library. cheers Bill
