On 04/30/2010 09:10 AM, Bob Wyman wrote:
Brion Vibber <[email protected] <mailto:[email protected]>> wrote:
> That Atom payload dates from 2008 and was introduced
> for compatibility with XMPP-enabled Twitter clients..
>. remember when Twitter had an XMPP interface? :)
History can be important...: I think you'll find that this use of Atom
was also intended to follow the "Atom over XMPP
<http://xmpp.org/internet-drafts/draft-saintandre-atompub-notify-07.html>"
specification that a number of us have been advocating for since 2004
or so... The use of this specification was certainly the subject of
discussions that I had with folk at Twitter and with Evan Prodromou of
Identi.ca back in 2008. In fact, the initial Identi.ca/Laconi.ca
implementation was modified from its original in order to more closely
follow the Atom over XMPP spec (of particular interest to me was
getting support the the atom.source element).
It should also be noted that this particular application -- real-time
pushing of blog (or micro-blog) content over XMPP was a regular point
of discussion during the many years that we debated the Atom format
specification itself. As far as I know, the first implementation of
"Atom over XMPP" was done by PubSub.com (my old company) back in 2003.
(Since micro-blogging didn't exist at the time, we only pushed blog
content.) Anyway, the decision to use Atom entries in this context
wasn't a casual or random one. It is something that we'd been talking
about for years.
Odd as it may sound, if you're looking to remove "unnecessary" stuff
from the XMPP messages, then you probably should be looking at cutting
down, not on the Atom entries, but rather the XMPP chat stuff. These
messages are simply *not* chat messages... In an ideal world, XMPP
clients would understand the XEP-0060 message formats or at least
"Atom over XMPP" and thus, the messages would be sent out without the
chat tag or data on them. The only reason that the chat overhead is
there was in an effort to provide backwards compatibility with
existing clients that were limited to chat-only. Unfortunately, folk
don't seem to remember or internalize the idea that XMPP was intended
to be more, much more, than just a chat protocol and we were supposed
to be able to send more than just unstructured text messages over XMPP
links...
We've got two primary use cases for XMPP on StatusNet & identi.ca today:
1) near-real-time delivery of an individual user's messages to a regular
chat client and allowing them to send outgoing messages through that
chat client (text+HTML chat message is required; extra Atom stuff is
dead weight)
2) near-real-time delivery of the site's public timeline 'firehose' to
other services for indexing, republishing, etc (extra Atom stuff is
probably used, but we're not really sure who's consuming what)
And a third case which we're not entirely sure exists, but if it it does
it'd be nice to keep supporting it:
3) near-real-time delivery of an individual user's messages to a
dedicated microblogging client (extra Atom stuff is probably what the
client wants to consume, as that's the data they'd otherwise be polling
for in the HTTP API)
Case 2) bumps up against the use cases for Atom-over-PubSubHubbub, which
is where a lot of the service-to-service activity seems to be going
these days, but if people are making good use of it over XMPP I've got
no desire to disrupt the service. (XMPP has some great advantages too,
such as not requiring your client to be public-net-accessible as long as
you've got an XMPP server out there!)
If case 3) has some good real implementations, then it would be great to
be able to push the Atom data out only when it's actually going to be
used. An extra 4k isn't too awful for a desktop chat client in
real-time, but can really add up if you have offline delivery.
In both cases, I'd want to make sure that if we do discovery/detection
that the receivers that need Atom will actually respond appropriately!
Is anything currently deployed that already does this without tying into
pubsub, which isn't used by what we've currently got?
-- brion vibber (brion @ status.net)
