On Fri, Apr 30, 2010 at 16:02, Bob Wyman <[email protected]> wrote: > Brion Vibber <[email protected]> wrote: >> use cases for XMPP on StatusNet > You've got three use cases, two of which need the Atom data and one (use > with dumb chat client), without question, doesn't need it at all. (note: > "dumb" is not meant in a pejorative sense) I would suggest that if you > really, really want to optimize the dumb-chat-client case then you might > consider offering two alternative jids for folk to subscribe to. Do minimal > chat-only content on one and offer the "Atom over XMPP" feed (potentially > with none of the chat overhead) on the other. But, please don't eliminate > the Atom stuff entirely. I think you'll find that it *will* be used, even if > it isn't well used today.
For Status.net I would think an option to enable Atom-over-XMPP would work: default - XHTML-IM only "fat" - Atom over XMPP This is also something that could be handled by having two PubSub nodes. > bob wyman > On Fri, Apr 30, 2010 at 2:30 PM, Brion Vibber <[email protected]> wrote: >> >> On 04/30/2010 09:10 AM, Bob Wyman wrote: >> >> Brion Vibber <[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" 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) > > -- Bear [email protected] (email) [email protected] (xmpp, email) [email protected] (xmpp, email) http://code-bear.com/bearlog (weblog) PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
