Consider using uri_prefix instead of uri_scheme for backend delegation

[adamcik]

Would allow for things like soundcloud mathcing http://soundcloud.com things and handling them instead of stream, which would just be a fallback. We could also just have a generic fallback where if nothing claims it we simply give it to audio and hope for the best.

[dz0ny]

👍

[txomon]

Supporting both is too nut? I mean, at the end is to match both of them against the begining of a string, isn't it?

[adamcik]

There is a bit more to it when multiple backends can service the same request. Either first one in order that returns a non empty list wins, or we have the first one that returns a list win, returning None for the I don't know case. So this needs to make those changes in core + test changes.

[adamcik]

@tkem - any thoughts how a uri like podcast+http://www.example.com/mypodcast.rss should be parsed. One approach I've seen is treating it like scheme = podcast and then considering the stuff after the plus like a localpart similar to how you would in mail.

[tkem]

According to RFC3986, + is a valid scheme character, so the scheme would be podcast+http.

[adamcik]

This could also be done more along the lines of an routing system (think web apps) or a rewrite system. The latter would simply be a hook that allows backend to rewrite URIs before the regular URI handling kicks in.

[adamcik]

Idea just came up on IRC that dz0ny's mopidy android app could have intents registered for the extensions we support, so in that case we would need to make this into something that can at least map to android's intent filtering or just outright mimic it.

[jodal]

The plan is to implement core.get_uri_prefixes() right now and remove core.get_uri_schemes() in v1.0.

[adamcik]

I've been thinking over this based on the somafm bug I commented on. I think we want to allow backends to pass on answering things about prefixes they've claimed. This would allow things like having an extension handling library methods like get_images, but ignoring playback ones like translate_uri. This would be needed as long as we have the prefixes at the backend level, and not on each provider.

This would be fairly simple to do for single URIs, just get a list of backends and try them one by one until one does not pass. For cases with multiple URIs it gets more complicated, at least the way I'm imagining things, i.e. we would need to make sure the semantics are simple enough.

Trying to write this all out I realized we can probably get away with a simpler approach, we pick the backend with the longest prefix match and a provider of the right type. With this change things like somafm would work as they don't have a playback provider, so we would fallback to stream, while still using somafm for library calls.

[adamcik]

Started adding a helper for prefix matching, and will try with the simplest thing we can get away with.