GNOME OPW Bi-weekly progress report

The past two weeks were very productive. After the first two weeks of take-off stage, I felt much better working on the code. I have gained a great amount of hands-on experiences from networking protocols to code debugging and git use. My major progress was about the library gssdp. Specifically, I have submitted bug 678744 and bug 678660. The bug 678744 was tracked down by using clang. I really like clang‘s colorful outputs and strict syntax check. The bug 678660 is about to use the newly introduced multicast functions in glib-2.32 to replace the gssdp’s own in-house counterparts. The good thing about these new functions is that the support of ipv6. gssdp doesn’t support ipv6 by now, so I hope my work can realize that which evetually will fix another bug.

Another thing worth mentioning is that I noticed that make check would fail if you were running VPN client on your host. For the coming weeks I’m looking forward to fixing more bugs.


GNOME OPW GUPnP Progress Report

Hi everyone,

I would like to write my first progress report on my Gnome OPW project, GUPnP. In the past two weeks, I spent time on getting familiar with the GUPnP project and its sister project Rygel. And I want to share my understanding here.

Different from many other Gnome desktop applications which usually have pretty graphical user interfaces, GUPnP provides the underlying supports behind the stage. It servers as the communication infrastructure for the upper-level applications. It is invisible for the end users but it is a hidden hero.

GUPnP actually consists of several small library projects, e.g. gssdp, gupnp, gupnp-av, gupnp-dlna and gupnp-igd. gssdp (together with libsoup) wraps the network details providing the HTTP-based communication capability such as resource announcement and discovery. gupnp with other gupnp-xxx stuff built upon gssdp implement the UPnP specification. More details can be found on the official website of GUPnP.

Rygel is a media-sever and media-renderer over the home-based network. It is the primary user of GUPnP and heavily based on Gnome/GLib/D-Bus components. To understand what the media-server/renderer/control are and how these things change our digital life, I would recommend to look at the demos at the front page of The best way to get the first-hand feel of these concepts is to actually use Rygel or run the test programs in GUPnP source folder.

First, prepare a folder with your favorite songs in it, then run Rygel in the same folder, and then use XBMC player (I recommend) to search the shared songs and play them. So what is the big deal, you may ask. The main idea here is that you can run Rygel in one computer to share your songs, and use XBMC at other computer to play. Imagine that you can also play your songs over the network in your Android/iPhone device too. All right. Do it. You will understand what I’m talking about. Meanwhile I noticed that a good documentation is missing on Rygel website. So I think I can contribute on that even though I’m still a beginner too.

Another thing that really sparked my interest is the use of D-Bus in Rygel. I have known for long that D-Bus techniques have been widely used in GNOME but I have never had a chance to go deep to understand its ins and outs. A nice feature in Rygel is that it exposes its service on a ‘bus’ so that other external programs can connect to this ‘bus’ and use Rygel’s media-sharing capability. At present, I can only scratch the surface without understanding the real story underneath. Hopefully by working the code of GUPnP and Rygel I will do that soon.

All right, summarize my progress. I have to admit the barrier to entry of networking programming is a little high. I finally made some progress on this bug. As what Jens suggested to me, a specific and non-trivial contribution would be to replace the multi-cast socket code in gssdp with the newly available function in GLib-2.32. I’m working on it now. So again, stay tuned. Welcome back to my blog to see what I will have.