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
