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.

I got the Views framework implemented a few days ago. Basically, it makes for a nice way to create new Medialib views by just dropping in a few files. Right now, the only thing missing is dropping in a css file, that should be fairly issue. On the python end, it's just a class with a common method that returns the correct data back. On the javascript end it's a similar process, an object constructor gets called which acts as a class for the view and does all the javascript work. The interesting part is the loader, which adds the script tag to the HEAD DOM Node. This is nice since it means we only load the javascript file if we need it. I've run into a weird problem though, for some reason if I do it this way, this file gets cached and no form of reloading will refetch the file. This is good from a user prespective, reduced downloading, but from a development prespective it's really problematic since to make changes i have to clear my cache.

So, I learned the wonders of MochiKit.Base.bind() and MochiKit.Base.method() they fixed all the problems i was having with status by explicitly binding this to the Namespace objects. All the issues I had been having with Status before since the namespace conversion have been fixed. Quite sweet!

The other thing I did was remove all the explict calls to update the playlist. I was able to remove them by replacing them with a check to see if the playlist has changed on the server side. This isn't as great as using xmms2 async and listening for xmmsc_broadcast_playlist_changed events, but it at least reduces the gratuitous reloading of the playlist for events that don't necessarily require it. Next big thing will be to manipulate the playlist instead of regenerating it complete each time.

In my grand namespace conversion I've run into problems with method binding, the problem is that this is only this when called from inside the object/namespace. So things get messy when you call into the namespace from outside or anything like that. I think this is causing a number of strange problems, for example when I add a song status stops working altogether. So I was happy to read about MochiKit.Base.bind() which binds a method to an object so that references to objects become less confusion. I'm hoping that this will help to solve these problems, but right now it's 4:48am and I can't be required to understand code anymore.

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).

So last night I talked to my mentor and decided my first target should be to ressurrect the /mediainfo controller with my new PropDict. The idea behind the controller was to reduce the size of data pushed into javascript space. The way it mostly works now is that when you request anything that has metadata, for example playlist or medialib view, it pushes out a complete mediainfo dict for each entry in that list as a list to javascript space via the controller.

/mediainfo was basically a way to make lazy loading possible. Instead of returning lists of mediainfo dicts the other controllers would return list of medialib ids and then /mediainfo would be called to get the medialib dict when it was needed. So with that we can resolve parts of a list as it's being exposed.

I was accepted to work on release engineering and general cleanup/development for XMMS2's web client, TurboX2. I'm so excited!