Brion Vibber <[email protected]> wrote: > XMPP has some great advantages > [over PubSubHubbub] too, such as not > requiring your client to be public-net-accessible > as long as you've got an XMPP server out there!) Yes, of course! That's intentional! If PubSubHubbub (PSHB) did everything XMPP did, we'd be having a very different conversation... :-) But, PSHB is explicitly designed to be a server-to-server protocol. This was done in recognition of the fact that there are, and would be, a great variety of "last mile" delivery mechanisms for transporting streams of messages to final-destination clients. PSHB *intentionally* avoids replicating what XMPP or any of the other "client-friendly" protocols does. The assumption is that in most cases, XMPP will be used by intermediate servers to take PSHB data and then, after some processing, forward it on to final-destination clients. PSHB and XMPP address, at least in part, orthogonal issues.
> 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. 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<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) >
