On Tue Apr 29 21:48:04 2008, Curtis King wrote:
On 29-Apr-08, at 2:43 PM, Peter Saint-Andre wrote:
Curtis King wrote:
I have one question why? I see absolutely no return for this
work, as it
safes what 2 round trips.
I think the main driver is simplification of stream handling (we
will be
living with the core XMPP stream negotiation protocols for a long
time,
why force all the newer implementations to jump through the same
old
hoops?), but I'll let folks who are closer to the code speak to
that.
I found it added no complexity in implementation. Also, since you
would have to send a new capability list after TLS and SASL
negotiation anyways I would argue the existing stream restarts is
simpler than avoiding them ;-)
Indeed - I'm not even sure it saves round-trips, given that it's
client-speak-first.
This is not terribly valuable work, and I don't see any reason to
devote any effort to it, especially given that we'd be stuck with the
"old style" more or less forever.
One more thing - for many stream restarts, these could have been
stripped in RFC3920 - prior to us deploying. But for some, it's
largely impossible - consider, for example, a switch to EXI. In this
case, you'd need to restart the stream, since you'd need to bootstrap
a new parser. (It'd be possible to spoof the <stream:stream> element
start tag, but, well, hackery-dackery.)
So in summary:
a) Lots of effort for minimal gain, and perpetual legacy support.
b) Gain is mostly æsthetic.
c) Sometimes, that gain is a loss.
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
