So, It's been a while since I posted. I've been doing a lot of crazy work, not limited to such things as writing an EventLoop for javascript. It's modeled somewhat after glib, it has sources which can either be JSON that is fetched periodically, or a method that is called periodically. For each source you can attach handlers which are passed the results of the source on completion. It also has better exception handling so it can often times recover better. This is much better than the old method where I had the status poll being used as an eventloop, calling out to gather status and then going about doing numerous periodic tasks unrelated to status without any real error hanling.

The first thing I did is finally understand how to implement multiple XPCOM interfaces in one Javascript class.
I finally found the answer in mozillaZine : it's needed to implement the nsISupports interface wich simply says wich interfaces your class implements.... and yes, it works good ! So now, my prototype has a *beautiful* progress meter to show the advancement of the download.

At the end of the day I met one of the mentor of the WinLibre organization who works under Linux, so he tried to make my prototype work on this machine, with quite some modification after he leaves, the prototype (so will be the final application) is now fully cross-platform (at least Windows/Linux, maybe I should see with solydzajs for the Mac part). I said "fully cross-platform", but as the application only download Windows installer, on Linux they can't be run, but all the other parts works fine, that's great ! :)

Now that I've tested on separate "test-apps" all the functions I would like to implement in my first working prototype I think I'll now begin to code a very early prototype.

The first thing to do will be to organize my files and to create the branch on the CVS repository.

Then I'll have to begin making a "distributable" code.

One day lost on a "known bug and limitation", grrr !
http://developer.mozilla.org/en/docs/E4X says "E4X doesn't support parsing XML declaration (<?xml version=...?>)", why didn't I noticed it ??!
Ok, I'm not the only one to blame I think... Why the hell does javascript report the "xml is a reserved identifier" when you *forget* (is the XML still valid without this declaration ?) to remove this declaration and how does it want you to know where it came from !?
It remembered the lack of error reporting of RDF, but thanks to my last re-reading of the docs, I finally find the answer, hurrah !

Well, yesterday I did the CSS namespace conversion so today I started on the JavaScript namespace (everything was in global namespace before). I now have a Commands constructor and can instantiate a Commands object with:

commands = new Commands();

So now that commands are all in their own object/namespace I can access them like commands.addEntry() It's nicer this way because I've had some problem with stuff bleeding into the global namespace and confusion other functions (like i had one function with an artist variable that was confusing another function that also had an artist variable).

One of those nasty things I had to do in my PropDict implementation was scary for-loop hell. So I've been worried about performance. Today I decided to look into how MochiKit finds indicies of entries in an array since that was largely my problem. What I learned was they did basically the same thing as me, iterate and compare (though they use their nice compare() function instead of if ( blah == blah ). At this point I decided to write a little benchmark app. It takes the start time, calls a function, takes the end time, and then swaps the time for a List Entry on an HTML Page (MochiKit.DOM \o/). What I learned is that the time difference between the implementations is almost negligable, usually within 0.001 seconds aside from some weird times where one call will take a seemingly long time. I do think I need to make the benchmark more complete testing a variety of functions and usage, but conversly it seems that either implementation would work.

Metadata in XMMS2 is returned to users in a custom data type we call a PropDict.
XMMS2's MediaLib supports writing data arbitarily to the Media Library, but for any
data written to the medialib one must set a source. So to make this source data
avaliable XMMS2 has the PropDict. A PropDict in Python is something like:


{('source', 'key'):'value'}


This is perfectly valid for a Python datatype, but can not be serialized to JSON.
Since most of the magic for TurboX2 is done in JavaScript we can't make use
of a standard PropDict serialized to JSON, so we reformat it. The reformatting