[standards-jig] IBB: Making it all "go"
rcb at ceruleanstudios.com
Thu Apr 10 01:46:09 UTC 2003
> Now, i know that if the server implementations worked properly, other
> than the offline storage issue from the s2s latency, it would be
> reasonable.. but, still very irrelevant to the definition of the
> <message/> packet.
I disagree; I think of 'message' as an envelope. Maybe it's got a letter
in it, maybe it has a CD, maybe it has a package of DVDs I just ordered
from Amazon.com. If I've moved, it gets forwarded to my new address.
Maybe it's something totally useless to me at the new address -- an
advertisement for a sale at some store right by my old house -- but it
still gets forwarded, and it's up to me to figure out what to do with it.
Yes, the offline problem is a real one for IBB. But I think it's a problem
for /anything/. What if I send some nice big PGP-encrypted xhtml-formatted
message to you in a chat and, due to s2s latency, it gets stored offline.
The hypothetical cellular phone is going to be equally unhappy with this
large wad of data it likely doesn't know how to do anything with ('pardon?
PGP? What's that?') as it would be with IBB.
And here's an example of where the existing behavior of message would be
/beneficial/ to IBB if leveraged properly: let's say I have a file transfer
going. My 802.11b drops me for a minute or two; when I reconnect, the
packets I missed are waiting for me already due to offline storage. The
final packet has something requesting an ack -- no packets have been sent
beyond that since it hasn't gotten an ack yet -- and so I send the ack, and
the file transfer picks up, magically, right where it left off. I know
some people who are on dialup who would swap to Jabber /specifically/ for
self-resuming file transfers!
> I dunno if <message/> is at all a viable solution..
I still think it is. To draw yet another analogy (yes, I'm fond of them),
think of the HTTP protocol. As far as I understand it, IQ is the HTTP
commands -- 'GET', 'PUT', 'HEAD' and so on -- which establish a session.
Message is the actual data stream; it could be html, it could be graphics,
it could be Flash, it could be raw TCP via an HTTP proxy. Maybe you have a
problem with the way the stream could be handled on the client -- web
caching, for instance. Does this mean you decide to encode the data in the
HTTP headers instead of the stream? Generally not; you do something like
define a 'no-cache' field in the headers.
My understanding might not be wholly accurate, but it really does seem like
anything which is the equivalent of HTTP headers (version data, timestamps,
caching information) would be in IQ: jabber:iq:version, jabber:iq:last,
jabber:iq:time, etc. A simple query/response or set/response. I can see
IBB being justified as being set/response inasmuch as each packet would be
a set, and the flow-control ACK would be the result... but it just /feels/
I think the reason for it feeling wrong is that in my understanding, Jabber
(and even moreso XMPP) is not supposed to be solely an instant messaging
system. The three core presence types, as far as I know, are intended as
presence notification (presence element), communication between different
resources (message element), and query/response for information between
different resources (iq element).
If we are making the assumption that <message/> is used only for text
messages displayed to the end user, then we are tying that element rather
implicitly to only the instant-messaging aspect of the whole system, which
has some rather striking implications for various things (such as
JEP-0072's support of SOAP via message packets).
If the behavior adopted for <message/> in terms of offline storage and
redirection is sufficiently troublesome in this situation, then maybe it
needs to be examined overall? Or else perhaps the definition of what IQ is
and what message is needs to be clarified? :)
Just my (spammy) $0.02 + state sales tax...
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the Standards