On 7-May-08, at 2:31 AM, Dave Cridland wrote:
Secondly, I'd dispute any lack of clarity caused by them anyway. If
you're going down this road, I'd like to see evidence of actual
interoperability problems caused by this alledged issue.
Thirdly, it won't make the specs any cleaner - instead, it will
simply cause confusion, as both restarting and non-restarting
implementations - both clients and servers - will exist for many
years to come, and both methods will have to be supported in all
implementations in order to interoperate.
This can not be under estimated. The implementation costs of removing
stream restarts out weigh the returns.
Because I'm in mischievous mood ;-)
If we are going to change streams lets dump XML protocol framing and
use something else which allows us to send either binary or text data?
Now that's a significant return.
Something like,
* Message Syntax:
*
* msg = header payload trailer
*
* header = msg_type SP msgno SP size CR LF
*
* msgno = 0..2147483647
* size = 0..2147483647
* msg_type = 1*<any CHAR except SP / CTL>
*
* payload = *OCTET
*
* trailer = "END" CR LF
Ok, back to reality. All successful protocol's have warts, rough
edges, and limitations. That's ok. What really matters at the of the
day is the number of interoperable implementations and deployments.
Please see BEEP for a "perfect protocol" with next to zero
implementations. Does it really matter XMPP isn't "real XML"?
ck
