[standards-jig] IBB: Making it all "go"
rcb at ceruleanstudios.com
Thu Apr 10 19:41:34 UTC 2003
> As for 1: in almost every real world case you'll *want* to have an ack
> packet, for the various reasons mentioned (flowrate control,
I disagree; in a real-world case, I could very definitely want the ability
to turn ack on or off. What if I want to do the equivalent of a UDP
connection over IBB, where I don't really care all that much if I lose
packets or not? I can think of a few situations where this would be ideal
(such as streaming media, though admittedly whoever does streaming media
with IBB should probably be shot by server admins).
Assuming IBB has to mirror TCP's behavior in terms of guaranteed delivery
seems like a fundamental oversight to me, especially when it's possible to
add control over the ACK and thus emulate either UDP or TCP, whichever is
more appropriate for the stream in question. :)
> As for 2: I don't see any "philosofical" reasons why we couldn't use
> <iq/>. Sure, if <message/> would be fixed the same would go for
No; there's no real /technical/ reason (other than losing the ability to
emulate UDP, which is actually a concern for some things I'd like to see
later). There /are/ definitely philosophical ones.
There's no technical reason (other than sheer 'eeew? WHY?!' factor and
BASE64 encoding bloat) that I can't encode a webpage entirely in the
headers of an HTTP result as BASE64 strings either, and eliminate the HTTP
stream. But it's not what HTTP headers are designed for so (as well as
being architecturally repulsive) it's not philosophically correct, and this
doesn't seem like what IQ was designed for either. :)
> - It's a simple JEP and with it you can do perfectly what it's designed
> for, both in theory and the real world. Why complicate things?
Because taking the path of least resistance doesn't seem like the best way
to ensure a solid protocol?
Have a Canadian nickel; I'm out of pennies to give my $0.02. :)
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