Bob Wyman wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
This would be an excellent idea if what we were talking about was a
low volume site. However, a site like LiveJournal generates hundreds of
updates per minute. Right now, on a Sunday evening, they are updating at the
rate of 349 entries per minute. During peak periods, they generate much more
traffic. Generating 349 POST messages per minute to perhaps 10 or 15
different services means that they would be pumping out thousands of these
things per minute. It just isn't reasonable.
Using an open TCP/IP socket to carry a stream of Atom Entries
results in much greater efficiencies with much reduced bandwidth and
processing requirements.
At PubSub, we've been experimentally providing "Fat Ping" versions
of our FeedMesh feeds to a small group of testers. We publish messages at a
rate much higher than LiveJournal does -- since we publish all of
LiveJournal's content plus everyone else's. We couldn't even consider Fat
Pings if we had to create and tear down a TCP/IP-HTTP session to post each
individual entry.
There are many situations in which HTTP would work fine for Fat
Pings. However, for high-volume sites, it just isn't reasonable. The key, to
me, is that we establish the expectation that the Atom format is adequate to
the task (whatever the transport) and leave the transport selection as a
context dependent decision. Thus, some server/client pairs would exchange
streams of Atom entries using the POST based Atom Publishing Protocol while
others would exchange essentially the same streams using a more efficient
transport mechanism such as streaming raw sockets or even "Atom over XMPP".
First off, as a general FYI, take a look at PaceSimpleNotify... the
current version uses basic HTTP POSTs to send one or more individual
atom:entry's to a remote endpoint. I'm hoping that the folks on the
protocol list will pick this up in discussion in the near future as it
is something that I definitely want to see incorporated.
Secondly, I believe that the format is more than adequate to support
this kind of mechanism. I do not believe that Brad's atomStream
container is necessary. Either just stream a bunch of atom:feed or
atom:entry elements directly over an open TCP/IP or a persistent
(keep-alive) HTTP connection. By no means would I ever suggest a new
HTTP connection for each ping.
- James
