There, SoC is over! Not much updates here along the way, but I managed to reach all my objectives, which means collections are now operational in XMMS2! More thorough testing will happen when clients start using the new API, and I will of course keep working on the project to fix things, finish the last details and help make it into the release after the next. But most of the work is over, which means it is now possible to create dynamic collections, use party shuffle playlists, query the medialib without writing SQL queries, etc. I posted a mini-HOWTO to show how to work with collections using the standard XMMS2 cli. More details can be found on the concept and the design pages of the wiki.

According to one friend of mine, who shall remain unnamed (you know who you are), I don't post on this blog enough. So strap yourselves in boys and girls, because here comes a new post.

The DAAP transform is in place and mostly finished! Barring a few kinks, it's ready to use, and it works much better than I had initially expected it to. Yes, the syntax is a bit stubborn; yes, iTunes struggles with it on occasion, but that'll all be worked out as time goes on. I think it's best at this point to move on to another phase of the project -- adding Bonjour/Rendezvous/Zeroconf/Whateverothernamesexistforthisprotocol support!

Also, if any of you have access to a Mac, I _highly_ recommend checking out XCode's MallocDebug (thanks to Tobias for pointing it out to me). While running the program, a little gnome** jumps into your code, roots around for a bit, then screams "HEY! That leak you're looking for? It's right *here*." This program is like magic, it practically points directly at any memory leaks it finds. I patched about 5-6 leaks almost instantly. Plus, it was a big help in fixing an ugly 300KB leak (yeah, there really is that much data to sift through, and my music collection isn't even that big). If you have access to it, use it. You'll thank me later. ;)

**I may or may not have made this part up.

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 posted a first version of the Collections Design wikipage, for now mainly focusing on the collection API and the development roadmap. Things are getting clearer and more concrete, thanks to brainstorming and Anders' ever lucid advice.

The implementation phase is now starting in parallel, with a merge of some refactoring of the current API as a warm-up (had been sleeping in my git tree for way too long).

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.

School has kept me busy lately, but I finally managed to complete the Collections Concept specification page. Things are much clearer now, and I shall start working on the implementation design right away!

Feedback is still welcome about the page above of course.

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.

So. I've converted the SongList of the Medialib view to use PropDict! There are still a few lingering bugs which I need to pop, and some more optimization would be nice. This of course uses the /mediainfo controller which means that we get temporary entries and then we swap them out when the mediainfo request calls back.

I also started on the quest to normalize my CSS namespace, which is now mostly done. This is a nice thing to have because it starts to make sense why things are where they are and the likes. It gets kind of confusing trying to figure out what you're swapping out when the CSS ids are ambigious things like ``entry.'' So that's fixed mostly now, with the occasional commit to chase a mistake or a forgotten id.

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.