06 July 2007

Favicon - check!

Finally, favicon retrieval support is here. What is this all about? Almost all IM protocols out there allow you to specify and associate an image to your account (a so called avatar), either natively (e.g. Y!M), either through extensions (e.g. XMPP/Jabber). As RSS isn't quite a "real" protocol, the need for an image represeting a feed isn't the first feature you'll look for, or ask for.

But as the basic features were implemented, I thought it would be nice to have some more visual clues as to what feed the user is currently reading, so the favicon spring to mind almost naturally.
(The favicon is a file usually called favicon.ico - hence the name :) - located in the root of the webserver. Browsers usually use it to identify bookmarks, shortcuts, tabs or the address in the address bar. There's also a standardised way of specifing favicons which allows for bigger flexibilty, but that works only with (X)HTML files. )

So basically, today's patch retrieves (if possible) the favicon.ico from the server originating the feed, decodes it (using the excellent AC.lib-ICO library), chooses the biggest/most colorful icon in case the icon contains multiple images, converts it to PNG and returns the binary representation of the image).

Why converting to PNG you might ask, and you are right to do it, as I asked that myself too :) . From what I could understand from the code and the documentation, the one who develops a plugin for a certain protocol has to implement in the ContactXXXImpl class (where XXX is the name of the protocol) the method getImage() which, to my big amazement returns a byte[]. Yep, a byte array. That is then decoded by the ChatContact class that takes care of the GUI part of SIP-Communicator.

While this may contribute to some separation between strictly speaking protocol implementation and the GUI usage of this implementation, I do believe that avatar retrieval AND decoding should be done by the protocol implementation. What if some obscure protocol uses an equally obscure image format for the avatar? The only solution is that of an intermediary image format (the very hack I used). Wouldn't this be a lot more elegant if each protocol implementation should deliver an abstract, already decoded Image? or BufferedImage? or no matter what image that does not need further decoding/deserialization?

I'll end this post here, with the hope that I didn't upset anybody with my rhetorical questions, and that the bits and pieces shared here will help someone.

HTML formatting, here I come! :D

No comments: