[standards-jig] IBB Again
rcb at ceruleanstudios.com
Sat May 3 08:02:05 UTC 2003
> Most use-cases of IBB will need this semi-reliable behavior: Avatar
> exchange, File transfer, Games, Data tunneling, etc. What kind of
> use-cases will need unreliable behavior?
Webcam. Voice chat. Anything where UDP would be suitable.
Half of my objection to iq in the first place was that I /can/ conceive of
situations where I would want a UDP-style transport. The other half is
that I still think that message is 'the right thing,' and it will take a
great deal to sway me. I still think of IQ as http headers, and message as
the data stream. :)
> When I proposed JEP-0041 (REL) earlier this week, I was criticized for
> thinking too far ahead. In particular, pgm noted that we should create
> protocol as needed, rather than try and make some perfect protocol that
> covers cases we don't care about yet. Keep this in mind when answering
> the above.
I read pgm's statement as having been that we shouldn't think too far
ahead, but that when a need for a protocol /does/ arise, it should be done
right. As protocol reveals additional needs, things adapt; as in this
case, the needs of a desired protocol forced the creation of message
delivery semantics, which I think are generally useful and will provide
other protocol options in the future.
Or to put it more concisely, I would argue that yes, there's a need for
this protocol...and now that the need has arise, it should be implemented
correctly with regard to the future.
> Acknowledgements, like message events? I know there was some talk
> earlier that IBB should not rely on a non-standards-track JEP (in this
> case, -22), so maybe these same features should be rolled into -79 ?
Perhaps. Or perhaps JEP-0022 should be made standards track? I lean more
towards that, honestly...it is widely implemented and is useful enough that
it should be a standard feature. 'course, I'm obviously going to argue for
that since I'm the one who suggested using 0022 for flow control and still
believe it's not only a well-suited match, but utilizes existing protocol
and satisfies the aforementioned 'only redesign what's needed to do things
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