On Jan 17, 2008 6:42 AM, Rachel Blackman <[EMAIL PROTECTED]> wrote: > > Seriously, we're talking about breaking a really good protocol for > > information that is only mildly useful... > Sure, but then recognize some people will iq:version flood because > they'll feel the need to query an entire contact list.
It is true that the users 'require' this. > My only real point is that end-users /do/ want this functionality. > And it's functionality which they presently have (being able to see > the client info of one of their contacts). Taking away existing > functionality rarely goes over well with end-users. If we're all fine > with saying 'screw the end-users, they don't know what they really > want,' that's fine, but I'm pretty sure at least one client author had > chimed in earlier about how end-users were unhappy when they removed > that information before. That was me, and yes - removing the full iq:version query from Psi caused quite an outcry when we replaced the iq:version flood with caps based versioning, and only doing iq:version when directly queried. > Personally, I'm fine with just the 'query only on mouseover or message > window open' or whatever, but I do then think we need to make a best- > practices XEP. Otherwise, we will have people who go, 'okay, I'll > just query and cache for everyone when I first see them' and we're > right back to version floods. (Or if we're fine with the iq:version > floods, that's cool too, but we need to explicitly be fine with that.) I confess that I'm starting to wonder what the difference is between iq version floods and presence floods when you log on. > Honestly, I think the best bet is an optional n='whatever' as a > display name in the caps field; takes up very little additional space, > and if it's there you use that for a display. That can say 'MyClient' > or 'MyClient 1.0 (Win32)' or whatever. You just use the string. > Otherwise, you just don't query. The string seems fine, although we probably don't want to mandate not querying, since clients may withhold it from global presence, but let some people iq:version. > I do agree that this bit can be pulled out of the caps discussion at > this point, though; the only bearing it had on caps was that > previously the node#ver values of the original caps meant that you > could map that to a specific disco#info identity string as well, so > the functionality had (unintentionally) rolled into the old caps. I think it's pertinent in as far as if it drops from caps, the replacement needs to appear at the same time, but other than that, sure. /K
