Joe Hildebrand wrote:
On Jan 18, 2008, at 9:58 AM, Peter Saint-Andre wrote:I think that spreading the load is preferable. I know my IM service would be happier if it didn't get this huge load spike when I log in with my ~1750 contacts. ;-)Picked a random place to jump into the conversation again.What if the client devs that want the information that they are currently getting from the disco#info for caps just cache based on a node+ver+v basis, rather than just a ver basis? They don't lose anything they currently have, they do a minimal number of requests, etc.
So caps would include everything from XEP-0092 except name and OS. Since I agree with you that including the OS is problematic (it unnecessarily opens a security hole), why not just include the name in caps and be done with it? Does n='Psi' add that many bytes to worry about? Or are you concerned about the fact that the name is not localized?
Sure, clients could send an iq:version request once upon receiving caps for a given node+ver+v from a given JID, then cache that across sessions. But I can hear the complaints coming already: "I develop a web/mobile/whatever client and I can't cache across sessions so I'll have to send iq:version requests every time". And I think this objection will be common enough that we might as well include n='client' (probably about an extra 10 bytes on average) in every presence stanza.
Yes, this is "wrong" at some level because the name doesn't change regularly and therefore it doesn't really belong in presence, but you could make the same argument about 'v='. And in any case it may be less wrong than iq:version (which we would now use only in cases where presence is not shared between two entities).
If including 'n=' enables us to finally finally finally put XEP-0115 to bed, I'm all for it. It is mildly annoying and it offends the desire we all have for clean protocols, but we've already held our noses over caps so many times now that I've lost count. ;-)
Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
