Songbird Source Released

Rinisari writes "The source for Songbird, a music-oriented XULRunner application, is now available via Subversion. Rob Lord, CEO of Pioneers of the Inevitable, released the source for the not-yet-0.2 version of the music player, which integrates a music library and the facility to purchase and download music from a variety of vendors. If you haven't heard of it, read the features list and try it out. Slashdot previously mentioned Songbird when it was released as a preview in February."

What's that quote?

[Lord Ender]

A caged source can't sing?

Why XUL?

[kahei]

Is XUL a good application platform? If so, why?

It doesn't seem to have much to reccommend it at first glance -- a language that lacks features and performance (javascript) a runtime that's bulky (mozilla), and worst of all a real case of Java-itis -- XML files and source files that endlessly have to be kept in sync and bundled together, no self-documentation and no metadata.

I ask because I tried porting a semi-complicated IE plugin to XUL and had to give up -- admittedly, I had to give up because of limitations in the HTML renderer, but long before then I had learned to dread the process of hooking into Mozilla at all. And that's saying something, considering that the original IE plugin was entirely made of hand-written COM, written against IE's none-too-predictable interfaces.

So, why XUL? I appreciate that you _could_ write an application in it, but what's the unique selling point that justifies all the work?

Re:List of XUL Applications?

[PoprocksCk]

Well for starters, Firefox, Seamonkey and Thunderbird will be able to run on top of XULRunner soon. That'll be especially nice for us Linux folks who prefer shared libraries over having multiple copies of the same duplicated libraries installed on our systems.

Re:Why XUL?

[kahei]

To be honest, your reply comes across as 'don't use XUL'. Being cross-platform (to platforms that have Mozilla available and installed) is hardly a big unique selling point that justifies a whole new way of doing things. As you point out:


To be sure, you don't need to do XUL- you can do the application in Qt, GTK+, Fltk, and a few others and get
the same results with less effort unless you need some HTML rendering support
...and even if I do need HTML rendering support, I can embed a browser or launch a browser or use an HTML control, or use Java or (on a good day with the wind blowing S by SE) Mono or Ruby+[binding].

So, why use XUL...

Re:Why XUL?

[bcmm]

Is XUL a good application platform? If so, why?

There are other cross-platform systems, but none which integrate as well with the system's look. The browser component is nicely integrated. It's very easy to use HTML + CSS to render interface components.

It doesn't seem to have much to reccommend it at first glance -- a language that lacks features and performance (javascript) a runtime that's bulky (mozilla), and worst of all a real case of Java-itis -- XML files and source files that endlessly have to be kept in sync and bundled together, no self-documentation and no metadata.

It isn't written in Java. Javascript isn't even anything to do with Java. Also, it doesn't run inside Mozilla or even require Mozilla to be installed. I haven't looked at the code, but poor commenting and source management isn't an issue with the language.

I ask because I tried porting a semi-complicated IE plugin to XUL and had to give up -- admittedly, I had to give up because of limitations in the HTML renderer, but long before then I had learned to dread the process of hooking into Mozilla at all. And that's saying something, considering that the original IE plugin was entirely made of hand-written COM, written against IE's none-too-predictable interfaces.

Why is it a good idea to try and "port" something like that? Neither the interface nor the language have anything in common, and in any case you just said the code you were trying to follow wasn't very nice anyway. XUL doesn't even work in a similar way to COM. That sort of thing calls for a rewrite from scratch.

So, why XUL? I appreciate that you _could_ write an application in it, but what's the unique selling point that justifies all the work?

You could I suppose... At least some of the Mozilla suite, Firefox, Thunderbird and Nvu are pretty nice applications, don't you think?

The DRM question

[Kadin2048]

Yeah I was kinda wondering about how they're going to manage the whole DRM business.

It sounds like it will support DRM-ed music stores (they mention Yahoo's subscription service, I think); how they're going to accomplish this I'm not sure of. I can only assume that each service will have its own binary blob for parsing and playing back its own files, and then the interface will pass commands to these blobs?

Still seems like it would be easy to get around: if the DRM parts are compartmentalized, how hard would it be to lie to them? For example, let's say you have a subscription-music service that makes all your music expire after a certain date if it doesn't get a 'keep alive' reset command. Couldn't you just keep passing it the wrong date? (This is a trivial example, I'm sure that the system would pull its time off the internet from an authenticated, trusted server, but it seems like there could be other attacks that would take this form.)

And if the music player software actually has access to the decrypted audio stream that the blob produces (for example, if it has a graphic equalizer, or visualizer), then it's pretty trivial to make the software do conversion as well. I can only imagine that even if you asked people not to implement such features, they would be in such demand that people would put them in and distribute modded versions regardless. (And, if it's GPL OSS, you can't really do anything about this.)

I don't see how the DRM components could possibly be open source. As I think we all know, DRM relies fundamentally on obscurity: you can't build "open source DRM," because then you just make the inevitable reverse-engineering happen more quickly. And I don't think you can have a subscription music service without DRM (unless it's like eMusic's, where you get a certain number of downloads per month). I guess what I mean is that you can't have an "all you can eat" subscription service without DRM, at least that I can imagine.