extragear/multimedia/amarok/src

[Daniel Winter]

On Saturday 02 August 2008 15:26:21 Maximilian Kossick wrote:

>
> Daniel is right. current.xspf's purpose is restoring Amarok's internal
> state after a restart. Using the internal uidUrl for current.xspf (or
> any other internal playlist). We do have to distinguish between
> internal playlists (even if they are stored as files), which use
> uidUrl (and will work even after moving files around if everything
> works correctly) and external playlists ofr use in other applications,
> which must contain the actual url of the track.


Well, in that point you get me  wrong *g*

I think storing the uidUrl (it was url() before) is the best for internal 
playlists.. 

Only for exporting we should use playableUrl().  

That way collections could return what every they want as url() (now uidUrl())  
do identify a track unqiue even after a move of the file on the filesystem.

I already use that for NepomukCollection to make playlists which even work 
after moving the files arround on the disk.   

It didn't break anything.  Other collection (for example some remote 
collections) could also use that to just use some id which that service is 
using.  

Also it alows for faster trackForUrl() as a collection can direct say "no" for 
a track when there is a url like amarokcollection_sqltrackuid:/ or something 
like that.  

So i see no problems for that, I even see a need for that.

And export playlist and some dbus api functions is the only place where we 
have to make sure to use the correct url() function. 

If that should not get used in this way, for what should that used then? I 
understood it that way, that that is the exact use case for that thing in the 
meta api.

DanielW