[...]
I slightly disagree here. But not enough anymore to really object.
I would dearly love you to disagree here. Not only because I'd rather like
to be wrong, but it'd be just like the good old days - and in any case, I'd
rather get the debate aired rather than raised later.
Well, I was never attempting to optimize the s2s traffic as measured in
number of bytes. My goal was always to reduce
a) the number of bytes fed to the xml parser (even though i learned some
nice tricks you showed on this list :-)
b) the number of stanzas. The assumption here is that there is a fixed
cost per stanza, consisting e.g. of
a) stringprep for from/to
b) privacy list checks
c) in-roster-checks (espcially loading the roster from storage for
clients which are offline)
In any case, I should probably note that while I'm more open to
representational changes than I was, I'd still prefer something that
remained beneficial if compression is used.
It's pretty hard to increase the traffic by compression. So the
effectiveness of compression, as measured by the compression ratio will
decrease, but that is not bad.
b) Security within the XMPP network has improved dramatically over the
past few years in terms of authentication and encryption. In addition,
in the last year I'd say, thanks to the raised level of awareness because
of the xmpp.net tool.
Certainly much of the improvement is down to Thijs. But we're comparing to
what, 2008?
well, I think I could connect to 1% of servers with trusted certs +
external in early 2012.
