On 18/10/05 4:39 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> > Eric Scheid wrote: > >> Ask yourself these questions: which is the "first" message in this thread, >> and if you wanted to understand the thread would you start there, or at the >> most recent entry in this thread and read backwards. Remember that by the >> time you've read back to the initial posting there would likely now be even >> more entries into this thread, so where would you then read them from ... >> where you started and going forward in time, or would you jump to the most >> recent and then read backwards until you hit a message you already read? >> > This makes perfect sense if you're a human reading messages, but now try and > understand it from the point of view of a computer program (an Atom > processor). The computer doesn't care which messages came first. > Yes, the _computer_ does *not* care. So why should it's preference trump the human reader? I imagine a future where a client application would offer up feed documents rendered all pretty, and offer up any links to other feed documents as links the client application will itslef render rather than passing them to a HTML browser. Thus, a Feed Browser in the same sense as a HTML Browser. Do you want to explain to future users why the "next" link gives them last weeks news instead of next weeks news? > It's not going to try and read the messages and make sense of them. It just > wants to retrieve all the documents in the most efficient way possible. Do things efficiently then. Remember though that the computer does *not* care if the token is 'next' or 'prev' or even 'foobar'. Does *not* care. > First off is has to start with the most recent document since that's what the > user is going to subscribe to. From there, the most sensible thing to do would > be to keep following links back in time to older and older archives until it > has retrieved all of them or (if this is a feed that has been downloaded > before) until it reaches an archive that it has previously retrieved. Did you say "back" in time? Your explanation is riddled with references to going backwards .. the aggregator/developer frame of reference is "going backwards", so of course the "next" object would be the one marked as being prior to the one your are currently on. That is, the next feed to process is the one marked @rel='prev'. Depending on what meta-data is available, and which axis you wish to traverse, and in which direction, then the link to the object you wish to retrieve after processing the current one could be "next", "prev", "hotter", "colder", or "foobar". The usage of the word "next" in describing the sequence of actions is entirely dependent on the purpose of those actions, and quite possibly completely detached from the meaning of the content being processed. The @rel='next' and @rel='prev' links however are part and parcel of the content. They describe the content. They are provided by the content publisher. They don't describe some third party's desired course of action. > I don't dispute that you have valid reason for thinking that forwards in time > is the way to go, but please don't assume those of us that think the opposite > are necessarily insane. But that would take all the fun out of things ;-) e.
