This is just to inform everyone that I do realize that a hard dependency on tracker is not the way to go and this is just a temporary measure. I am writing a gstreamer/gio based metadata extractor as we speak. Although I'll try my best to get this done before GUADEC at least, it might take longer since I do this on my spare-time (something I don't have in abundance).

Disclaimer: I am not against tracker and I *will* keep the current tracker-based media source (as a plugin), though i might need to drop that as a temporary measure for while until i get the plugin system implemented.

network-light:
- Remove the unneeded periodic notification to susbscribers.
 [Zeeshan Ali Khattak]
- Create a new UUID for each instance of network-light.
 [Hugo Calleja, Zeeshan Ali Khattak]
- Use the new gupnp_root_device_new() API. [Jorn Baayen]

universal-cp:
- Display the device presentation URL [Ross Burton]

general:
- Fix `make distcheck`. [Zeeshan Ali Khattak]

- Correct function prototype. Fixes #940. [Jorn Baayen]
- Include the glib header to satisfy vala-gen-introspect. [Zeeshan Ali Khattak]

- Add tool for generating convenience C wrappers for GUPnP service definitions.
 [Ross Burton]
- Remove xmlDoc argument from gupnp_root_device_new() for simplicity.
 (xmlDocs can still be passed to gupnp_root_device_new_full())
 [Jorn Baayen]
- Better documentation, new tutorials and sample code. [Ross Burton]
- Improved support for Accept-Language header. [Jorn Baayen]
- Various internal improvements. [Zeeshan Ali, Jorn Baayen]

I finally managed to port all the existing C code to Vala. What did i achieve from this exercise? For one thing, the code got much simpler, with LOCs being reduced from 2101 to 1117 (46.8 %). Also this proves that (at least the server-side) GUPnP's Vala bindings are already in a stable/usable state.

Special thanks to Jürg Billeter, Ali Sabil and Jussi Kukkonen for their continuous support during this exercise and for quickly fixing bugs that I reported.

So yet once again Mr python decide to tease me when i do `apt-get dist-upgrade`:

Setting up python-lxml (2.0.5-1) ...
/var/lib/dpkg/info/python-lxml.postinst: /usr/bin/pycentral: /usr/bin/python: bad interpreter: No such file or directory
dpkg: error processing python-lxml (--configure):
 subprocess post-installation script returned error exit status 126
...
Errors were encountered while processing:
 epiphany-extensions
 bzr
 gnome-media-common
 libgnome-media0
 gnome-media
 pidgin
 python-lxml
E: Sub-process /usr/bin/dpkg returned an error code (1)

Meet my new personal hero, Jussi Kukkonen. The only o-hand employee in Finland who almost single-handedly created the Vala bindings of the whole GUPnP stack and ported all our test apps to Vala in a very short amount of time despite the fact that he was completely unfamiliar to Vala and GUPnP (and UPnP itself) when he started working on this task and the fact that the Vala documentation is hardly any complete (especially binding-generation).

When I told some people that I will write (which involves re-writing existing code first) the gupnp-media-server in Vala, their question was "Why Vala? Why not Python, Java or C#?". So here are the strong points of Vala, not all of which are found in these languages:

• Statically-typed
  
  Back in the days, when I was hacking on Gazpacho I found the lack of types on variables and function/method parameters really annoying in Python. This can become quite a pain when you are reading other's code and that is exactly what I was doing most of the time. The fact that Johan and Kalle wrote very nice and readable code, helped a lot though.
  


• No runtime dependency/overhead
  
  This might seem like a small point to many developers but as an embedded-systems developer, this is a big plus for me and I am sure to many (if not most) of the embedded-systems developers out there.
  
  


• Easy integration with C/GObject
  
  A big plus for all the GObject/C developers out there. Besides, there are situations when writing code in any language other than C or C++ is not possible/viable and such easy integration would make life very easy. Recently a colleague of mine had to bind a gobject-based library for Python and it turned out to be a lot more pain than I imagined. This impression is based on the fact that so many of GNOME developers have taken python so serious and so many of the GNOME apps are being (re-)written in Python.
  
  This point is very important when it comes to writing frameworks and libraries since if you write them in a language that doesn't qualify as a LCD, you are pushing your choice of language on the application developers you aim to attract. Since Vala translates to a language that does qualify as LCD, it in turn also qualifies as one.
  
  An important bit here is that this integration is bi-directional, i-e one can use the classes written in Vala very easily from C. In fact this is much easier than doing it the other way around as you don't have to write any bindings.
  
  

UPDATE:I am sorry if my ideas hurt someones's feelings attached to some particular language. If i have hurt your feelings, there is no need for insults, I didn't force you to read my blog. Just writing this after removing an insulting comment from an 'Anonymous' dude.

- Use libsoup 2.4. [Jorn Baayen, Zeeshan Ali Khattak]
- Incremental browsing of containers. [Zeeshan Ali Khattak]