Open PierreRust opened 9 years ago
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.
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:
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!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?
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.
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 :
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 :
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
andartist
, but these endpoints are optionnal so a client should probably not rely on these for it's base features.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 :
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 :)