[Playlist] resolving multiple <location> elements per <track> in XSPF?

[Lucas Gonze]

Wayne,

The cardinality of the location element is "zero or more." This was chosen
instead of "zero or one" with the intention of supporting both of the use
cases you mention (fallbacks and alternate media types).

What VLC and Audacious do in only using the last location is an incorrect
implementation.

That said, our strategy was to make it easy to build a weak resolver, and
possible to build a strong one. If VLC or Audacious become stronger over
time by adding support for redundant locations, that is the process playing
out as hoped.

I wonder what we can do to help this happen in the VLC and Audacious
communities.

-Lucas


On Mon, Dec 12, 2016 at 12:45 PM, Wayne DePrince Jr. <waynedpj at in-giro.xyz>
wrote:

> ahoy all,
>
> for parsing an [XSPF][1] document, the [specification][2] states that [a
> `<track>` element can have zero or more `<location>` elements to define the
> URI of a resource to be rendered][3].  for example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <playlist version="1" xmlns="http://xspf.org/ns/0/">
>   <trackList>
>     <track>
>       <location>http://example.com/song_1.ogg</location>
>       <location>http://mirror.xyz/example.com/song_1.ogg</location>
>     </track>
>     <track
>       <location>http://example.com/song_2.ogg</location>
>       <location>http://example.com/song_2.mp3</location>
>     </track>
>   </trackList>
> </playlist>
>
> my question is whether this is for allowing:
>
> - multiple locations of the same type of resource (e.g. MP3 file at
> original source and mirror) as in song_1 above?
>
> - or for different types of the resource (e.g. use multiple locations to
> provide both an Ogg Vorbis and MP3 version of a track) as in song_2 above?
>
> - or maybe both?  and/or others?
>
> currently VLC and Audacious both use the last `<location>` provided in a
> `<track>`, even if it is not available.  thus they seem to simply be using
> only the last `<location>` element, which does not seem to be what the
> specification intends.  either way they do not perform either of the
> resolve cases i list above.
>
> obviously how these locations are interpreted changes the expected
> behavior of a resolver of `<track>` elements that include `<location>`
> elements.  the first case provides a nice fallback solution.  more
> interestingly for me, the second case simplifies the times when 2
> playlists would be needed: 1 for Ogg Vorbis and 1 for MP3 versions of the
> tracks, as would have to be done with M3U and PLS for example.
>
> thus: is there an standard or recommended behavior for handling/resolving
> multiple `<location>` elements for a single `<track>` in XSPF?
>
> thanks
>
>   [1]: http://xspf.org
>   [2]: http://xspf.org/xspf-v1.html
>   [3]: http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.1
>
>
> PS: also posted to StackExchange
>
> https://stackoverflow.com/questions/41101769/multiple-
> location-elements-per-track-in-xspf
>
>
> --http://waynedpj.in-giro.xyz
>
>
> _______________________________________________
> Playlist mailing list
> Playlist at xiph.org
> http://lists.xiph.org/mailman/listinfo/playlist
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20161212/69f35352/attachment.html>