Antone Roundy wrote: > XMPP: > 5. If the feed had entries that were old and not updated, go to step 7 6. > If the feed has a "first" or "next" or whatever link, go to step 1 using > that link 7. Open a socket 8. Send "login" XML stanza I am assuming that if you are pushing entries via Atom over XMPP, you would only push new and updated entries. Thus, a client shouldn't need to check for "old and not updated" entries. Also, I'm assuming that since you are pushing entries, you wouldn't be inserting "first" or "next" links that needed to be followed. The client would get all of its entries from the XMPP stream.
> XMPP could achieve parity in getting feed changes that occurred while > offline, at the expense of implementation complexity parity, by > polling the feed once upon startup. My assumption is that any well-built XMPP feed reader will, in fact, also be able to read Atom files via HTTP. This is what we do at PubSub and Gush does the same. I think Bill's app also does this. The original question dealt can, I think, be summarized as: "How does one best keep up with a high-volume Atom publisher?" My point was that the "first" and "next" links don't make things any easier. They just force the client to do a great deal of work to discover what the server already knows -- which entries have been updated. The "first" and "next" links approach just makes the process of working with feed files more complex as well as more bandwidth intensive. XMPP support is a much better solution for keeping up with changes while connected. Let's keep Atom as it is now -- without the "first" and "next" tags and encourage folk who need to keep up with high volume streams to use Atom over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are good things. bob wyman