Scope of the mandatory part of the API

[PierreRust]

Great work here, the work towards 'standard' API' for music library has made great progress : It's a very good news :)

I have many comments I want to share but my main concern at the moment is that I fear the mandatory scope of the API is not large enough.

As far as I understand the goal is to allow a music player to access a music library, managed by a another program, in a standardized way. When looking at various player applications, we can see that there is, in respect to library, a set of core features that they (almost) all implement :

• playing music (!), which means accessing audio files
• library searching
• library browsing : usually by genre, album artist and album
• playlists

I've tried to look at the API and see, for each of these three features, how a client application could implement it.

Playing music : Accessing audio files is implemented with the tracks/(id)/audio endpoint, no problem here :)

Library browsing :

• using the tracks endpoint, you can easily implement browsing at track level, but this is generally not convenient, and not common, for any average-sized music collection (anything more that 100 tracks propably, which very small actually).
• Album and artist level browsing can be implemented using the album and artist, but these endpoints are optionnal so a client should probably not rely on these for it's base features.
• filtering cannot be used to implement library browsing because is uses strict match and there is no way to get the list of all existing values for the album, artist or genre meta-data.

Library searching : filtering cannot be used, the only way to implement this is to make a full library copy in the client side.

Playlist : not in the spec. This can be done client side (but you need browsing first, in order to be able to create the playlist), but when using several client players connected to the same library it would be really nice to see the same playlist everywhere. This could easily be designed as an extension though.

As a conclusion, I fear the set of mandatory features in the aura specification is not enough to implement basic music player application : for a player that does not want to rely on optional feature that may not be available, the only way to implement library browsing and searching is to fetch the full list of tracks, keep it somehow in a cache and re-implement the browsing functionality on this copy. While this might be a good approach in some specific case (client who want to work offline for example) I think it is not a good solution in many case, especially for large collection and / or web-based client.

Actually I can only see two kinds of applications that can be developed using only the mandatory part of the API :

• rendered application (like an Upnp Renderer), which simply plays a stream when requested by some controller (but then the controller application but somehow provide library browsing). But in that case, you almost only need the audio endpoint.
• applications that make a full copy of the database and implement most of their functionalities on top of this copy. Several mpd clients do exactly that (cantata for example) because of the limitations of mpd protocol in regard to library access and I'm afraid the Aura API might reproduce these limitations.

Is there any reason I've missed to make the artist and album endpoint optional ?

PS : I hope it does not sound like a rant because it's really not what I want ! If there is some better place to discuss this kind on things, please tell me :)

[sampsyo]

Hi! I know it's been a hilariously long time since you posted this, but I'm suddenly excited to get to work on AURA again.

The short answer is: yes, I want AURA to be appropriate for all those use cases. So we should do whatever it takes to mirror what other APIs are already capable of.

Optional Album and Artist Indexes

This is a tricky aspect that I'm not at all sure about. It might be a good idea to reverse this decision entirely and make /aura/artists and /aura/albums mandatory. Here's what makes it so tricky:

• On one hand, it's possible to define these groups by "raw metadata," as many desktop audio players do. That is, if you want to see all the songs by The Band, you just need to filter the set of tracks to get the ones where the artist field exactly matches the string "The Band". If you want to see the set of artists in your library, that's easy too: get the list of tracks, get their artist fields, and essentially run sort -u à la UNIX. Simple!
• On the other hand, this is actually a naive data model. For example, there are several albums titled Weezer by the band Weezer, and it's quite common to have all of them in your library. This implies that servers should have a concept of "artist" and "album" that is separate from the raw metadata.

My original thought in making those endpoints optional was that I wanted to support both (a) simple servers that don't have a separate concept of "artists" and "albums," and (b) smarter servers that do.

But you're absolutely right that this could be seen as giving too much leeway. So, I think I want to reconsider this choice. Namely, let's make those endpoints mandatory, along with an explanation of how simple servers can achieve them. Something like this:

If your server doesn't have a separate concept for "artists" and "albums," that's fine. Users still, however, want to browse by artist and album—even if it's just by metadata. To implement the AURA endpoints for this purpose, you can exploit the fact that IDs in AURA are arbitrary strings. This means your server can use the identifying metadata for artists and albums as IDs. For example, /artists/The%20Beatles is a valid URL for an artist in AURA, where the ID of the artist resource is the string "The Beatles".

Does this make sense?

Playlists

I totally agree—it would be great to specify playlists in AURA. This would require a bit more complexity than the other kinds of "browsing," since you probably want to be able to create and modify playlists too.