[Playlist] an alternate xspf over json implementation

[Sebastian Pipping]

Chris Anderson wrote:
> 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/"];
>  }
> }

-------------------------------------------------------------
I didn't think of that. I agree the first way is much easier.
-------------------------------------------------------------



> 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.

-------------------------------------------------------------
I'm not sure if extension order really is insignificant.
The order of locations for example is significant and
I don't see why it should be different with extensions.
Lucas, does it matter? Is there a third way?
-------------------------------------------------------------



>> 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/"],

-------------------------------------------------------------
I didn't know this was legal JSON. No need to duplicate
the keys then. Cool!
-------------------------------------------------------------



> 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 think we should not introduce additional features
for JSPF. I think we should keep XSPF and JSON in sync.
If we really need more features we should make a successor
version of both JSON and XSPF in my eyes.



Sebastian