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.

Over the last week or so I have gotten an async connection to xmms2 to work by spawning the mainloop in a seperate thread. The upshot of this is that I am able to get xmmsc_broadcast_playlist_changed events, which basically give a description of atomic changes to the playlist. With this I am able to update the playlist only when and where updates are needed, instead of having to reload the entire playlist (as had been done in the past). Thanks to this feature I have started to implement methods for handling the different atomic events. Tonight I finished all of them except remove.

To test out how useable the playlist was I decided to load my entire medialib into the playlist. The performance during the load is awful (basically hard lockup of firefox while the playlist loads,) but once the playlist has been loaded the performance is quite acceptable. Any changes to the playlist happen without really effecting the user experience at all. Clearly the big problem is loading. This is partially the result of the loading process itself, which can be rather expensive. First a fake entry is added, while a callback is attached to get the results of a http request that gets the mediainfo PropDict from xmms2d. Once the data is in, the fake entry is swapped out for the actual playlist entry. This can be a performance hit since all of these events block, but it also makes it easier to implement lazy loading.

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.