[Standards] XEP-0115 redux
Rachel Blackman
rcb at ceruleanstudios.com
Tue Jan 15 17:58:17 CST 2008
> However, we could opt to stuff that information into the caps
> element anyway,
> just to save ourselves from having to transmit another element/xmlns:
Honestly, the only gain here is saving a few bytes (by not having
another entire element), and at this point, this no longer really has
any direct bearing on caps. After all, the only association
previously was that the disco#info identity element, and the client-
unique nature of the original node#ver query, dovetailed nicely to
allow you to cache client identity as an unintended benefit of the
design (since you got that information when querying the features
anyway).
With the node disconnected from the client identity, there's no longer
that tie; the only reason we've still been discussing this is that in
order to not LOSE previously-available information, clients would need
to re-introduce the iq:version flood (which I think EVERYONE agrees is
bad). So really, the client identity stuff doesn't conceptually
belong in caps anymore.
I DO agree putting client info like this into presence is a big gain,
since if it's there, you just use it, and if it's not there, you
assume the client does not want to offer it and do not go around
mucking up the network with floods of queries. But it's not
conceptually really tied to 'capabilities,' and arguably stuffing it
into XEP-0115 makes the XEP try to solve too many usage cases.
Conversely, as noted, the only gain from keeping this tied into
XEP-0115 is the saving of a couple of bytes.
(However, given how paranoid we as a community are about sticking too
much stuff into presence, that small bandwith savings may be reason
enough to merit stuffing it into caps.)
There's my take on it.
--
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards
mailing list