-
Notifications
You must be signed in to change notification settings - Fork 9
Potential Features
Possible extensions (or even core features), mainly inspired by Related Work.
We should probably provide at least a coarse-grained (all-or-nothing) authentication mechanism. Some guidelines:
- Like DAAP or Ampache, this should work by exchanging authentication for a session token. The session token should be passed along with all subsequent requests as a URL parameter.
- The server should report whether authentication is required (optionally, it can be wide-open; for example, when it's on a local network).
- It would be nice to avoid tying ourselves to passwords. One idea is something like OAuth, but that seems to heavyweight. Some manner of one-time codes would be nice. Not sure how to accomplish this smoothly without, e.g., sending email.
A standard extension should allow for PUT/PATCH/DELETE requests to modify the collection. This allows for fully-functional music managers as clients.
Clients should be able to sync the entire database and then efficiently ask the server for updates. At a coarse grain, this could work by just asking whether the database has changed (like DAAP). Or it could go full-on and report changes since a previous snapshot.
Like Ampache or GitHub's Play, let people vote on tracks they want to hear next. Then provide a playlist of the next songs to queue up.
Part of the goal is to support clients that run entirely in the browser. We need to investigate how difficult it will be for browser clients to securely interact with the Last.fm API to scrobble tracks. It's possible that they will need some amount of server-side support.
A few servers support a feature where you can download a zip of a given subset of music (possibly along with its album art).
It would be very nice to allow in-browser clients running separately from the server to access the API. Rather than JSONP, this should work with CORS. Perhaps the spec should mandate/suggest the use of CORS.
The base API supports exact matching on the assumption that clients will allow more advanced user-specified queries on the client side. Maybe some mechanism for writing more complex queries should also be provided as an extension (perhaps with undefined semantics).
There should probably be a standard extension for supporting a player on the server side, controlled by the client (along the lines of MPD, XMMS2, MPRIS, DACP, Mopidy, Groove Basin, and Ampache "serverplay").
A standard extension should almost certainly exist for exposing and editing playlists of music.
Groove Basin protocol has no concept of querying. Instead, you "subscribe" to certain things and then the server keeps you up to date using a delta format. For example you can subscribe to the music library index, and receive a full JSON dump of all the music library tags. When something changes you receive a tiny delta with the change. So clients can be easily written to be responsive and up to date. (Also consider how this helps the client always display the correct play/pause state.)
This requires a persistent connection. Over HTTP this means WebSockets, Server-Sent Events, or long-polling. The JSON Patch standard also seems relevant as there are many interoperable libraries for both diff and patch operations. Rocket is a proposal for using JSON Patch with Server-Sent Events to overlay streaming on top of ordinary REST resources.