[Standards] Client/version Display (was: XEP-0115 redux)

[Rachel Blackman]

> On Jan 17, 2008 6:42 AM, Rachel Blackman <rcb at ceruleanstudios.com>  
> 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.

I think what this boils down to is:

1) Client name/version display information no longer really belongs in  
caps.  We can all agree on this.  The fact that it was part of caps in  
the first place was less by design and more an unintended side benefit  
of the way caps used to cache on a client+version unique basis, and  
included the client display name (in the disco#info results) and the  
version (in the caps data).

2) We don't want to clutter presence further by cramming things in  
there, since everyone HAS to get presence, and then it'd be in every  
packet.  Fair enough; this would in theory waste more bandwidth than  
the old iq:version flood did anyway, since it forces the information  
on everyone whether or not they want it.  (After all, desktop users  
may care a great deal about viewing this information, but mobile phone  
users probably do not.)

3) Users demonstrably want this feature and will be upset if it is  
removed, as Kevin related.  This is a key point here; I think we often  
lose sight of how much our end-users can care about little features we- 
as-designers may think are meaningless.

4) Pretty much any solution that's been put forward involves per-JID  
caching of some form.  This means pretty much any solution will be  
something you need to probe each of your online contacts with.  Either  
with some sensible method (only probe when you mouseover and need a  
tooltip, or whatever), or just plain flooding the entire roster.

5) Given points 1-4, the old-school iq:version is actually starting to  
seem the logical solution, since it gives you the information on a per- 
JID basis anyway.  Possibly with a best-practices XEP if we care  
enough to discourage a straight-out flood.

I think we have an unfortunate tendency to focus on all sorts of  
aspects of the protocol that the end-users don't care as much about,  
while forgetting the sort of features they do.  Things like this -- or  
avatars, or showing whether you're on from a desktop client or a  
mobile phone client -- may seem like pointless frosting (and empty  
calories) on the protocol cake to us, and far less important than  
sorting out some nasty edge case for MUC, or coming up with the best  
way to tunnel RPC-XML through XMPP servers.

But (to stick with the cake analogy) the end users often care less  
about whether we used fresh vanilla in the cake or vanillin extract,  
and more about whether or not their piece of cake has one of those  
'pointless' frosting roses on it.

To us, the ability to show whether someone is online from a desktop  
client or a mobile phone may seem silly and almost feepish, but to AIM  
users, they can get really upset if the little 'mobile' indicator icon  
doesn't work.  And when I first tried to convince my parents to move  
to XMPP years ago, when people were still arguing that avatars were  
silly and unnecessary, my dad went back to MSN because on Jabber "I  
can't set myself to be the little space shuttle."  To him, that was a  
killer feature; he couldn't be the space shuttle on Jabber, and he  
couldn't see mom's little Zen garden avatar, and so he felt Jabber was  
a less-friendly protocol and went back to MSN.

That said, we've probably spent more than enough time on this aspect  
of the discussion.  So if everyone else is fine with just saying  
'users want this and iq:version is sufficient, let's just trust the  
client authors to query in a sane manner,' then let's go with that,  
move on with life and get back to more important things.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/