On Friday, June 17, 2005, at 12:32 PM, Bob Wyman wrote:
This is *not* simpler than taking a push feed using Atom over XMPP.
For a push feed, all you do is:
1. Open a socket
2. Send a "login" XML Stanza
3. Process the stanzas as they arrive.
...
For your solution, you need to:
1. Poll the feed to get a pointer to the "first link". (each poll
will cost you a TCP/IP connection).
2. If you got a new "first link" then go to step 5
3. Wait some period of time (the polling interval)
4. GoTo Step 1
5. Open a new TCP/IP socket to get the next link
6. Form and send an HTTP request for the next entry
7. Catch the response from the server
8. Parse the response to determine if its time stamp is something
you've already seen.
9. If you haven't seen the current entry before, then go to step 5
10. Go to step 1 to start over.
Not to get into a big argument (each method has its advantages
depending on circumstances), but allow me to revise the above a little.
The following assumes applications that attempt to keep you up-to-date
on changes to the feed that occurred while you were offline:
XMPP:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether each is new/updated or
not--if so, do the appropriate thing)
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
9. Wait for a stanza (sending keep-alive packets periodically), and
when it arrives...
10. Parse the XML
11. Process it (Determine whether the entry is new/updated or not and
do the appropriate thing)
12. Go to step 9
Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or
not and do the appropriate thing)
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. Wait some period of time
8. Go to step 1
The XMPP app will need to contain a superset of the polling app's code.
My assessment of which method wins on various issues:
Latency: XMPP
Implementation complexity: Polling
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP if you're trying to archive
the feed, otherwise no difference
Getting feed changes that occurred while offline: no difference
If we're not concerned about ensuring that we get all changes, the
story is different:
XMPP:
1. Open a socket
2. Send "login" XML stanza
3. Wait for a stanza (sending keep-alive packets periodically), and
when it arrives...
4. Parse the XML
5. Process it (Determine whether the entry is new/updated or not and do
the appropriate thing)
6. Got to step 3
Polling:
1. Open a socket
2. Request and get the feed
3. Parse the XML
4. Process the entries (Determine whether the entry is new/updated or
not and do the appropriate thing)
5. Wait some period of time
6. Go to step 1
My assessment:
Latency: XMPP
Implementation complexity: similar
Bandwidth consumption: XMPP
Resource consumption between polls or pushes: Polling
Getting all feed changes while online: XMPP
Getting feed changes that occurred while offline: Polling
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.
