[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Etan Reisner deryni at unreliablesource.net
Wed Jul 4 15:07:01 UTC 2007


On Tue, Jul 03, 2007 at 10:04:41PM +0100, Ian Paterson wrote:
<snip>
> >Joe Hildebrand wrote:
<snip>
> >>No.  The other reason for caps is so that receivers can show a different
> >>icon for each different client that they have received presence from.
> >>There has to be a URI to define the sending client.
> >
> >Yes, that cuts down on the old iq:version flood. Or so we hope. :)
>
> Hmm, going forward, are the clients that most people use going to
> continue showing these icons? Is this a feature we need to care about?
> Even though I'm one of the small group of people involved in the XMPP
> community, I really don't care what client my contacts are using. Will
> there ever be mass demand for this feature? On the rare occasions where
> people are interested, they'll probably be perfectly happy to explicitly
> ask their client to find out the other user's client version on a
> case-by-case basis.
<snip>
> - Ian

I am not exactly certain what icons are being discussed here or how they
were historically used etc.

But having just dealt with a significant change in the pidgin user
interface involving removal of the protocol specific icons from the buddy
list in favor of a generic 'available' icon I figure I would chime in with
our experiences about this sort of thing.

There was a small (but vocal) set of users who protested the removal of
the icons from the buddy list as being detrimental to the amount of
information they have at their disposal.

Most of the cases that people explained were the cases where they used
that information tended to be cases in which one of the protocols we
supported was less functional than another and they needed to be able to
select a buddy on the correct protocol quickly.

We dismissed this entire class of scenarios as being pidgin bugs that need
addressing, either by improving the protocol support where it was lacking
or by doing the right thing so that they didn't have to know one of the
protocols didn't support it (or support it well). [1]

The majority of the cases that remain after those dealt with above were
cases in which the users friends happened to use one protocol at home and
another at work, so the protocol icon information actually provided them
with location information. We dismissed these as accidental information
and indicated that better methods exist for handling this.

And the final set of cases were the people who liked it better 'just
because'. Which was dismissed as not being a reason.

Notably, we have only ever, in my entire time working on pidgin, received
a handful of requests for client identification and by a handful I mean
something on the order of 10s of requests.

So, long story short, I think assuming that many people will actively want
client identification icons for valid reasons (especially in a scenario
where you only have one protocol) is likely not to be a valid default
assumption.

All that said, we haven't removed the protocol icons entirely, we have
them for expanded contacts, in the buddy list tooltips, and possibly soon
in the conversation window. Because we realized that they do have purpose
in some places. Relating that to the case here, I think if the client
specific information has a place and a time it is perfectly likely well
served by specific querying at the time of conversation (or other
communications) starting.

	-Etan

P.S. Apologies for the length, but I thought the explanations were useful.

[1] For example, being able to send a file to a buddy over XMPP rather
than over MSN (where our current support is limited to server proxied file
transfers) without needing to specifically select the XMPP buddy. Or
sending an offline message over a protocol that does support them rather
then not allowing a message to be sent. (To explain a bit, pidgin supports
meta-contacts and only displays one conversation window per contact, so
that a conversation with a buddy over a protocol that doesn't support
offline messaging should allow for continued messaging over a protocol
that does support that when the buddy happens to go offline.)



More information about the Standards mailing list