On Fri Apr 30 17:10:59 2010, Bob Wyman wrote:
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...
Right - if the intent is to support non-IM clients, then sure, use
Atom, send useful data - albeit use the fact that XMPP is stateful,
and don't send the profile data every time, because that's just dumb.
But then, also, use PubSub, don't use IM constructs at all.
The key here is to send data that's useful to the receiver, and does
not include any redundant data the receiver (could, and should) know
about already.
> 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.
It's not.
I can prove it isn't - when it arrives at its destination - viz., my
instance of Gajim - it's just noise, and is thrown away. As a server
implementor, I'm actually more concerned with the storage of this
useless data on the server as offline messages, but it doesn't really
matter - it has ceased to be information.
The intelligent thing to do here is to use Atom for cases like
Identispy, or Identichat, and *not* for IM clients.
Then design a sane, efficient, protocol that microblogging over XMPP
can use effectively, and one that's sufficiently extensible that it
can cover a wide range of systems. Then "proper" XMPP-based
microblogging clients can use this XMPP interface, and not the
XMPP-IM one at all, to get access to their feeds and more.
The kind of thing you're advocating would yield an XMPP design where
PEP was thrown away and we shoved everything back into <presence/> -
something we conciously moved away from years ago because it was so
grossly inefficient.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
