[Playlist] an alternate xspf over json implementation

[Chris Anderson]

On 6/14/07, Sebastian Pipping <webmaster at hartwork.org> wrote:
> Chris Anderson wrote:
> --------------------------------------------------------------
> I thought about this again. I modified your extension
> proposal to actually see the difference:
>
>
> == ORIGINAL ==
>    "extension"     : {
>      "http://example.application.com":[
>        {"multiple":"instances of"},
>        {"an application's":"extension can coexist"}
>      ],
>      "http://another.application.com":[{"each instance":"arbitrary json"}]
>    }
>
> == MOD ==
>    "extension"     : [
>      { "http://example.com/app/1/" : ARBITRARY_EXTENSION_BODY },
>      { "http://example.com/app/2/" : ARBITRARY_EXTENSION_BODY }
>    ]
>
>
> I like the latter much better because
> * It fully preserves the order (ABABA will not become AAABB)
> * It is simpler, has one level nesting less (in a way "list versus tree")

I'm torn here. I see the benefit of your approach, as far as encoding
data goes. The trouble spot is in retrieving the data. Rather than
accessing an application's extensions directly in code, one has to
search through the array of extensions matches. The difference is
significant.

the old way:

my_jspf.playlist.track[0].extension["http://example.com/app/1/"][0];

the new way requires a function to find the first matching extension -
even more work if you want to find more than one extension body for
the same application.

for (var i=0; i < my_jspf.playlist.track[0].extension.length; i++) {
  var extension = my_jspf.playlist.track[0].extension[i];
  if (typeof extension["http://example.com/app/1/"]  != "undefined") {
    return extension["http://example.com/app/1/"];
  }
}

Correct me if I'm wrong, but extension order does not matter in XSPF,
so perhaps the usability gains here outweigh the costs of losing XML
ordering.

>
> Before I forget: If you look at the track locations you find this:
>
>    "location"      : [
>      {"location"     : "http://example.com/1/"},
>      {"location"     : "http://example.com/2/"}
>    ],
>

I'm not sure I understand the benefit here; the Rubyist in me just
wants to remove the duplication of the extra "location" key. I updated
the wiki thusly:

         "location"      : ["http://example.com/1/", "http://example.com/2/"],
         "identifier"    : ["http://example.com/1/", "http://example.com/2/"],

As well as requiring less bytes over the wire, the compact syntax also
means less typing for people using the JSPF object. To access the
first location of a track using the compact syntax, one codes:

my_jspf.playlist.track[0].location[0]

using the previous syntax, it's a little longer:

my_jspf.playlist.track[0].location[0].location

The only benefit I can see to the longer syntax is that one could hang
additional properties (above and beyond the spec) on the location
objects - maybe an application would want to provide average transfer
rates for a given location, or last_seen_at times for the urls - but
I'm not sure we want to encourage extra-spec properties nested so
deeply. eg:

my_jspf.playlist.track[0].location[0].last_seen_at   #=>
"2007-05-15T13:08:37-08:00"

Although I can see the appeal. :)

I really like the way you've handled the rel attributes for link and
meta elements. I was stumped for a method to manage that simply, but I
think you've nailed it here:

        "link"          : [
          {"http://example.com/rel/1/" : "http://example.com/body/1/"},
          {"http://example.com/rel/2/" : "http://example.com/body/2/"}
        ],
        "meta"          : [
          {"http://example.com/rel/1/" : "my meta 14"},
          {"http://example.com/rel/2/" : "345"}
        ],

I'm eager for everyone's feedback.

-- 
Chris Anderson
http://jchris.mfdz.com