Success! Google Summer Of Code

Well after all the micro-blogging at night and the IRC chat, and writing an exam, here is a really good post!

The proposal is Amarok and KDE UPnP Integration. I'll be working with mentor Bart Cerneels. This news was awesome! Last year I didn't get in for kwin-tiling, but I participated in Season of KDE and did a few other contributions all year and it paid off. This year I started of quite early and worked hard on the proposal. When the ideas list went up, Amarok UPnP integration seemed the most interesting to me. Since then I was in talks with Bart and started a discussion on the Amarok mailing list, that much to my surprise, was very responsive :-)

Now with the result out of the way, its time to start working as soon as my final exams get over this week. This will involve choosing a UPnP library and daemon for device discovery. The next step is to implement a KIO slave which can browse UPnP media servers like any other folder. The final thing will be to write an Amarok Collection which can index music on UPnP servers on the network. This involves filtering and sorting and also making the server play music when in the playlist :-), can't forget that. So its going to be a very eventful 3 months, with lots of commits, a T-shirt and lets not forget the money. Right now I'm waiting for the invitation to the private mailing list.

It was great to hear some stats. KDE got 50 slots, 11 Indians got into KDE, and 3 from DA-IICT got into KDE. Which is awesome! Sai Dinesh will be working on getting mobile phones working nicely with KDE. Aditya Bhatt will be working on Digikam face recognition. Others I know are Varrun Ramani, working on Amarok too, implementing Distributed Collections. Vishesh Handa will be working on Nepomuk, and finally the one and only :) Shantanu Tushar on Gluon. Happy hacking everyone...

KWin tiling is merged

I'm glad to announce that yesterday the kwin-tiling branch was merged into kwin trunk by commit 1118677!. It will be available in KDE SC 4.5. Please keep in mind that it is an experimental feature with rough edges. Bug fixes are already on the way, but some things, like session saving and so on are absent. Please do add feature requests and bugs to the KDE bug tracker.

This screencast should show off a few things. Apparently xvidcap produced really bad video, so I will have to do it again, watch out for updates here.

Thanks to Martin Graesslin for being my mentor during Season of KDE, and all the others who bugged me with emails about when tiling would be integrated into KWin :)

GSoC results now 13 hours away...

( Mamma, I'm not stressed out :-) )

Quick and dirty Instant Messaging with Redis

(Aside: Yes this is a post after a zillion years, but I have a few more lined up, and waiting for some important stuff in about a week)

Redis is a wicked cool NoSQL database, in that storing stuff is not the only thing that it does. Mathias Meyer already has a collection of Redis use cases, but this great idea is mine. Like all good ideas it emerged in the shower :) ( I was not aware of Pieter Noordhuis' MUC when I did this, in either case mine deals with one-to-one IM )

Using the new publish-subscribe commands and a bit of node.js code, here is a tiny instant messaging server. An explanation follows, refer to the code while reading it, Blogger sucks for publishing code.

Here is how it works. For every client, the server maintains two connections to redis. This is because a subscriber is not allowed to invoke other commands. So we have a subscriber connection and publisher connection. Consider two clients are now connected, Alice and Bob.

When Alice connects ( NICK Alice ), we insert her nickname into 'mclarens:inside', a Redis set. This allows us to have a WHO command to list online members. Bob to does the same. To start chatting with Alice, Bob initiates a conversation ( TALKTO Alice ). The node server does none of its own client management. Instead each client just maintains subscriptions to two channels/classes. Each client is always subscribe to '[nick]:info', where it is notified of talk initiations and exits etc. When Bob wants to talk to Alice, he sends a 'start Bob' to Alice's info channel, 'Alice:info'. Then both Alice and Bob subscribe to the class 'Alice:Bob', using alphabetical order to decide the name. When either of them wants to talk to the other, they do MSG [nick] [message]. The connection uses the publish redis connection to send a message to the channel, resulting in both sides being notified of the incoming message.

To terminate the chat, one side just has to send a 'STOP [nick]'. That unsubscribes the user from the class so that he no longer receives messages. It also sends a 'stop [nick]' to the other side, so that he/she can also unsubscribe.

On QUIT, we simply remove ourselves from the mclarens:inside set, unsubscription is handled automatically by Redis!

That's it, simple Instant Messaging! Now this lacks any kind of security and ignore lists and status but proves the point. In fact I'm thinking of using this as the backend for the IM part of the XMPP server I'm hacking on. At this point it is in no shape to have this feature just yet, but it should some day.

(Thanks to roidrage and tnm on #redis for pointing out that I had to use two Redis connections for PubSub.)