Summer of code final steps. A new beginning.

The Summer of Code finally ended and I must say ot was a great experience. It ended OK ;) and I hope I'll get my hands soon on the T-shirt and the certification Google is going to send after code samples come in.

However, this SoC was a very rewarding experience all financial benefits aside (which too, have their share in the "very rewarding" qualification. I must admit that without the financial incentive I doubt things would have gone on an open-source path this summer.). Still, seeing the insides of an open-source organization and getting to contribute to a piece of software people are actively using and even break into pieces to make their own pieces of software was by itself an experience worth every bit of work. For that, cheers to Google! :) I had the occasion to see many of the aspects I have read about in "Producing Open Source Software" by Karl Fogel "live", and that was a very interesting thing. At times I felt like reading a book and seeing the movie at the same time, going like: "Hey, it's like in the book" :) Very nice suprise, that book!

[...]

Event if this blog was supposed to tell only my experience with the 2007's Summer of Code I indend to keep posting from my future experiences with Sip-Communicator in particular, and software developement in general.

Right now, I'm planning my last month of holiday. I'd like to finish some of the tasks that were off the Google Summer of Code for the Sip Communicator and set up a little open-source project of my own that I dream about for almost three months.

All the best!

Javadoc fun

Teach us the holy knowledge of writing funny javadocs :)) - taken from the jUnit 3.8.1 Javadoc.

jUnit, testing, testing

I finally wrote and succesfully run my first jUnit test :) Yay! (in fact that was a couple of days ago, but who counts?) In a way it was easier than I expected, but in some other ways, getting it to run and give the proper results was quite a tedious work.
It was easier than I expected, because all my previous contact with unit testing was a couple of years back, when I attended a short presentation about TDD with Visual Studio 2005 Beta2. And at the time everything was quite fuzzy for me. But the official documentation and the actual jUnit package for the dummy Gibberish protocol in SIP-Communicator proved to be quite a source of excelent samples :) .
Getting it run, and with the proper results was, though a totally different chore, mainly because of all the OSGi stuff inside SIP-Communicator (which, I must admit, I still don't fully understand). It took me a couple of hours and some help from Emil to edit the 3 (or was it 4) configuration files needed for the tests to be properly run. All in all it wasn't big thing, but getting it right from the first try might be tricky. That's way, and because it was mainly a trial-and-error process, I'll make a quick outline below:

1. make sure your package mainfest file is correct (for the RSS this was rss.provider.slick.manifest.mf ). Care should be taken about which packages are imported using the Import-Package directive. No java.* (that includes packages like java.util or java.net) package should be included or Felix will throw an exception and won't load your bundle. This alone gave me a headache :D
2. Edit lib/felix.unit.test.properties in order both to include aditional packages you might use and also to include your slick bundle (in this case file:sc-bundles/protocol-rss-slick.jar) in the list of bundles started by the ant build test. Again, include only packages not provided by the runtime. One important thing to note here is that you must also include the bundle that provides your protocol implementation (in this case file:sc-bundles/protocol-rss.jar). Even if it may be outright obvious, I had some rough time figuring out why it couldn't find any protocol provider for the RSS implementation.
   
3. Create an Ant build target for your testing bundle and include it in the list of run targets.
4. If you want to run just your tests, you might edit lib/testing.properties and comment the lines corresponding to the other tests and add only your package.

If you made the above steps right you should have no problems running your tests and with the right outcome.
Happy testing! :)

check out. again...

It seems I do have a strange problem when it comes to using CVS. It's not version control systems in general, but CVS. Or at least, the CVS I'm using here, on Sip Communicator. Somehow, I never get it right. Each and every time I try to update my sources to the latest version in the repository something goes wrong and I end up with an uncompilable sandbox and a ton of error messages. And the final solution is always cvs co sip-communicator.
That was a little digression just to release some frustrations :D
The midterm review went fine, and I'm pretty pleased with the results so far. The reader looks a lot nicer now and I thinks it's a little more useful too. You can get to see a screenshot of the new plugin in the news section on www.sip-communicator.org. But, as the midterm went and passed the final evaluation is coming in pretty fast.
After some discussions with Vincent (of which I haven't seen that much recently) and Emil, the main things that should be ready by around 20 August are:

• a meaningful way of uniquely identifying items within a RSS feed (that's work in progress, hopefully I'll finish this tonight)
• making the online/offline button really work (right now you can sign-in/sign-out your RSS account but that will make no difference)
• marking unreachable feeds as offline (timeouts, HTTP 404's, HTTP 403's, HTTP 500's, you name it)
• least but not last, writing unit tests for the protocol

Hopefully, with a little help and counseling all the above bullets will get a checkmark. I had a block for the last dozen of days or so, and a problem on confidence (like being unable to write anything useful, with LOTS of times asking myself if I can do this or not), but Emil proved to be a great mentor, not only technically, but also on the more human side of open-source developement in GSoC :) Thanks man!
That's kinda all for today, I gotta go finish that patch.

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

Interim objectives

I know I've been a little late setting these, but now it's kinda' settled. So, here's what I ought to do by July 9th:

• implement retrieval of favicon.ico retrieval and using it as a contact image for the feed
• implement HTML rendering of the feed body (this should be paired by a GUI plugin for a more flexible configuration, but I doubt I have the time to finish it by the first deadline)
• squishing any bugs I found on the way (it would be nice if I could get rid of the most of the exceptions raised on different RSS feeds - news.google.com was just one of them).

Wish me luck or „ca va chier” as Emil puts it :))

Google politics

One of the problems well known in the current implementation of the RSS support in SIP Communicator was the inability to retrieve feeds from news.google.com (and you must admit, news.google.com is quite a source of news ;) ).

A brief look at the exception returned by the plugin points out the problem. The server is sending a HTTP/403 (Forbidden) response code instead of the HTTP/200 (OK) response code. This indicates that, for some reason still unknown to me, the news.google.com server totally dislikes our client. Having found that out, i started searching for the "guilty".

After examining a few Wirechark dumps, I had a clear idea of how the HTTP request we were sending looked like. I've tried it once more, by manually connecting to the news.google.com server on port 80 using telnet, and typing the request (not very complicated, as HTTP is, as you know, a plain text protocol). The result was the same HTTP/403. I've tried then the most simple "equivalent" HTTP request:

GET /?output=rss HTTP/1.0
Host: news.google.com
Connection: close

To my surprise, I received a nice XML file along with the necessary headers. So I started changing and adding headers to get as close to the request SIP was issuing that would still work. After about a dozen tries, I found out that the User-Agent SIP was sending along with the HTTP request (that is Java/1.6.0 on my machine) is somewhat on the blacklist of the news.google.com servers. I verified this assumption by changing the User-Agent for lynx and wget. As soon as the original User-Agent was replaced by a more exotic value (be it a totally dummy User-Agent like 'Kikiriki' or a well-known User-Agent like 'Mozilla/4.0'), thigs worked like a charm.
For now I've fixed that by adding a

    System.setProperty("http.agent",
                System.getProperty("sip-communicator.version"));

in the start() method of the RssActivator.

I still have some problems, but I don't know if they are caused by my pretty lame internet connection or there are other bugs in the code.
Right now I'm trying to figure if there's any other bug to catch and how to implement RSS contacts icons. But more on this later on today :)