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... > StatusNet's Atom feeds have gotten a lot more > verbose lately as we've been adding metadata > (PuSH, ActivityStreams etc)... This is both the beauty and the cost of using Atom. The format is capable of carrying a great deal of data in an easy to parse, structured format. It is certainly the case that many applications don't need the extra richness, but it is also very much the case that without that extra data, there are many applications that simply can't be built. Given that bandwidth is increasingly dropping in price and given that customer's demands for expanded richness of applications are continuously growing, it would be very unfortunate if any attempt was made to remove the expectation that "Atom over XMPP" is not the right way to distribute this data. bob wyman On Thu, Apr 29, 2010 at 4:25 PM, Brion Vibber <[email protected]> wrote: > On Thu, Apr 29, 2010 at 12:04, Dave Cridland <dave at cridland.net> wrote: >> >>> Any obvious first steps? Lose the Atom? Make XHTML-IM optional? How might >>> we >>> avoid forcing options on users? Disco for capabilities with positive >>> stickiness? >>> >> >> IIRC the issue is that they want the display capabilities that >> XHTML-IM affords but not all clients handle it the same so they repeat >> the data. The Atom portion is now standard for OMB and Activity >> Streams. >> >> IMO clients and servers should now "do the right thing" with Atom >> payloads and we can get rid of most of it. >> > > That Atom payload dates from 2008 and was introduced for compatibility with > XMPP-enabled Twitter clients... remember when Twitter had an XMPP interface? > :) > > StatusNet's Atom feeds have gotten a lot more verbose lately as we've been > adding metadata (PuSH, ActivityStreams etc), so those packets have indeed > been getting fatter... > > I'm not 100% sure anyone actually uses the Atom data in the XMPP feeds > anymore; before figuring out whether discovery would be worth implementing > I'd like to get some feedback from anybody who is using (or looked into but > chose not to use) that Atom block to find out if they'd be affected if we > just dropped it entirely! > > -- brion vibber (brion @ status.net) >
