[Playlist] Re: How to avoid music download?

[Jay Fienberg]

> From: "Lucas Gonze" <lucas.gonze at gmail.com>
>
> On 9/25/07, Chris Anderson <jchris at mfdz.com> wrote:
>> used by this player:
>> http://hypem.com/flash/time/today/xml/1/0/today.html
>
> Thanks for pointing that out.
>
> here's a track:
> <track>
> <location>N2NjZGZkYTJkMjc0ZTZmNGY3OTVmNmQ0Mzg4MTEzYTVjMTgyM2NhY2ZmYzI2 
> ZTAyMzE2MGIwMD
> Y1NjI4OTg5NzJlMzQ1ODA5MzUyYzBjZDllZjdlZDNhMmU2ZDMwYWM3NTFmZTEzNmM4YmRi 
> ODAzOGNmZTU1MThlN2EwZTFjNTlmOWIzZWE1M2U5YThlMDU1</location>
> <ituneslink>http://hypem.com/go/itunes/387628</ituneslink>
> <annotation>Born Ruffians - Knife (Grizzly Bear cover)</annotation>
> <info>http://hypem.com/go/track/387628</info>
> </track>
>
> So what would be better ways for them to do these tasks?
>
> The location should probably be moved into an identifier element.

It's weird to conjecture about a player that uses something almost  
like XSPF. I guess, technically, if one wanted to share a playlist  
that included non-resolvable location elements, it'd be better to not  
use the location element at all. Then, the encrypted code could be  
stored in an identifier element, or a proprietary element (since the  
player is going to doing something proprietary with the identifying  
code anyway). The main choice about using the identifier element or  
not probably could be around whether the encrypted code makes sense  
as a valid canonical URN identifier or not.

Another approach:

They have a player that uses location elements in a non-standard way,  
and expect the location elements to have something other than legal  
URLs. This could be designed differently using a "graceful  
degradation" pattern, i.e., using a legal, public, URL that standard  
players can interpret correctly, while their own player treats the  
public URL as the encrypted carrier of a private location.

So, their location elements could be done like:

<location>http://example.com/public/ermsgay/atwhay-eway-oday-isway- 
ecretsay.acflay</location>

encrypted (public) url:
	http://example.com/public/ermsgay/atwhay-eway-oday-isway- 
ecretsay.acflay

decrypted (private) url:
	http://example.com/private/germs/what-we-do-is-secret.flac

A standard player, going to the public URL could be served a "sorry"  
message that explains the site policy or whatever. (Or, served a  
"preview" of the song. . .)

But the proprietary player could decrypt the public URL to extract  
the real private URL of the song.

All the said, it's still a bit dodgy because then the track data in  
the xspf doesn't really match the resource available at the public  
url. That's why the "no location" approach seems better.

Jay


>
>> as in
>>> Jay Fienberg
>>>> http://jayfienberg.com
>>>
>>
>