I tend to see the same set of things done over and over again in clients as they go from "I only care about XMPP chatting" to "users keep asking us for better transport support". Many clients look for bare JIDs in your roster and treat them in a special manner, which is fine except in some cases I have bare JIDs in my roster and the service it's attached to is gone, so the client gets a little confused. Clients like Psi will dutifully look for jabber:iq:register and offer that as an option on services. Many of them you have to go disco browsing to find the transports available in the first place. Nothing wrong with any of that. Some clients may choose to go ahead and look for things marked jabber:iq:gateway and add them to some special list. That's not really what this is about though.

A number of clients will add in basically "hacks" for individual chat services. Psi has "service icon sets", and if it's a new service that isn't in Psi's list, it comes up with default icons. Spark has a bizarre mechanism in which it explicitly adds support for each individual transport via what I call little java "nuggets". But a common theme I see here is individually handling each service. Some new service comes along, now all of the clients have to be updated if they want to have cool icons. Personally I think that's crap. ;) I'm a big fan of dynamic lists of things. In other words a client shouldn't have to -know- about any of the specific transports. It should be able to simply pull a list of services on the server in question, if it wants gateway ones look for jabber:iq:gateway, and --- and here's the missing part --- be able to retrieve whatever it needs to provide a nice experience to the end user.

So what all tends to be custom added? Generally it boils down to icons. Icons icons icons. Icons for presence, Icons for representing the transport, etc etc. I don't think I've ever seen anything beyond icons that couldn't be determined from disco queries. So why couldn't service icons be provided by the service itself? I could see something along the lines of using pubsub where the transport publishes it's icon sets, one for service icons (maybe a set of different standardized sizes) and one for presence representation icons. That way a client could just come in and go "gimme the icons I should use" and move on. I admit my knowledge of pubsub is -still- limited, but my understanding is that there are version numbers associated with the published data, and the client could cache what it got and simply check for "is there a newer set?".

The primary caveat here that I can think of is, that pulls the 'control' of the icons away from the client and into the transport, and there's always a chance that the client doesn't "like" the icons the transport is sharing. Of course, for the most part the clients are aiming to use icons similar to those of the service the transport is providing, so they kind of already have to deal with the possibility that for example AIM's icon might not look great in their client. So the question is ... would client authors use this or just end up scoffing at icons coming from the transports themselves?

I suppose if the clients really felt like they needed to have different icons for some services, they could always override what they're getting from the transport and do their own anyway. It just always feels like a hackjob to me to see things like "if this JID matches with aim.* then use the AIM set". Especially those instances make me cringe because JIDs can be anything for those transports, where the transports -will- be providing a gateway identity that tells you flat out what service it is, assuming the transport authors bothered to follow spec. ;)