mopidy / mopidy-spotify

Mopidy extension for playing music from Spotify
https://mopidy.com/ext/spotify/
Apache License 2.0
930 stars 108 forks source link

Browse directory structure #66

Closed dirkgroenen closed 1 week ago

dirkgroenen commented 9 years ago

I'm working on the new Mopify client and noticed a slight difference in the way how opidy-spotify's directory structure is built up compared to the mopidy-soundcloud extension. Mopidy-soundcloud appends each newly clicked 'directory' after the uri, where mopidy-spotify radically changes the URI. Is there a reason for this, if not; would it be possible (and make more sense) to get this in line with each other?

For example when browsing through Spotify: spotify:directory changes to spotify:top:tracks instead of spotify:spotify:directory:top:tracks.

jodal commented 9 years ago

We could change it, but I really don't want to. URIs are supposed to be opaque. You shouldn't infer anything from their contents.

I'm guessing that you want a way to keep track of what's the parent folder to ease navigation. We've discussed some schemes for this in the past, and we'd like to include it in a future browse API if we can decide on a good solution. If you want to know more about this, it might be that we wrote something about in the core API cleanup doc, see mopidy/mopidy#1224.

dirkgroenen commented 9 years ago

Correct, I indeed want to use it to keep track of the parent folders. But for as far as I can include, soundcloud's scheme may be good for me know, but there's a pretty good possibility that it's gonna change somewhere in the future?

In my own opinion using a scheme where we browse through 'directories' makes the most sense. At the moment we have both soundcloud and Local Files doing that and it feels pretty natural (and makes it easier to integrate UI elements based on the structure). What's the reason you personally don't want to make the URIs hierarchical?

kingosticks commented 1 week ago

I'm not interested in doing this.