Status Update: Google Summer of Code (GSoC) Part 2!

Hello StatusNet Community! This is Derek reporting to you from StatusNet in Montreal. Our Google Summer of Code (GSoC) students have been hard at work with their mentors, and I have a feeling that you will be quite surprised to hear about what they have been working on!

Ian McEwen is one of the five students that has been working with StatusNet for the GSoC. He has been working on a project to create StatusNet-Music.

Ian's list of things that have already been accomplished

* Audioscrobbler API – it's even mostly working. The exception: when tracks are submitted without an mbid, automatic figuring-out of which album they are from can sometimes be wonky (specifically, for albums with more than one artist performing). All the more reason to tag your music with MBIDs!

* Basic artist/album/track pages, per-site and per-user – these mostly just have a list of the the listens plus pagination at the moment. In part to deal with the above problem with multiple-artist releases, if '_' is set in the URL as artist or album on a track page, or as artist on an album page, it is treated as a wildcard.

Ian's list of things to accomplish for around the end of summer

* Better artist/album/track pages – better linking among these pages (for example, to the whole-site page from the per-user pages, and vice versa, and links to other versions of the same track – for example, using the wildcards mentioned above); pretty graphs; and on track pages, comments (that is, @-replies to notices which are listens).

* Customization of the ActivityStreams data in Atom feeds – clearly listens shouldn't be in Atom as the default Activity verbs and nouns! There's a very nice 'play' verb and a very nice 'song' noun in ActivityStreams to be used.

* Subscribability – want to subscribe to every listen for a particular artist? Why not!

* Administrative interfaces – for things like merging albums/tracks/artists, and a variety of other twiddly things of utility.

* Data-export capabilities – this is twofold: One, some of the last.fm API methods provide exportation of data (e.g. user.getRecentTracks). Two, I think it should be possible to get a simple .csv file or such of all one's listens, so that users can do statistics on their own/keep ownership of their data/etc without having to learn an API.

Ian's list of things that are projected for after the summer

* Filtering – listening produces a lot of bulk notices. It would be awfully nice to be able to filter those out when/if they're not wanted. The same would apply to a lot of other 'noise' in notices, making this a prime candidate for another plugin. Shall we call it Sieve for StatusNet?

* Better information – on artists, albums, tracks, so forth. There's a plethora of information out there – if we can only figure out how to pull it in, and where to put it!

* Awesome musicbrainz integration – if we're going to be using their data, we might as well contribute back too, eh? I hope to eventually create some great ways to edit data in musicbrainz from statusnet-music, leveraging the power of a herd of submitted tracks.

* Your cool ideas – suggestions welcome! Push them all towards Ian over OStatus, email, or wherever else you can find him.

If this is something that interests you, and you would like to start trying out StatusNet-Music, you can access it on Gitorious, or if you would like an account on the development server to use for submitting tracks or just playing around with the interface, feel free to ask Ian for an invite.