[vlc-devel] Playlist synchronization with multiple interfaces

[Rémi Denis-Courmont]

Le perjantaina 24. elokuuta 2018, 17.11.27 EEST Romain Vimont a écrit :
> Another alternative would be to reject a request based on an older
> state. For example, the playlist could increment a "version" integer on
> every write operation, and every write-operation would pass its current
> "version" from which the changes are applied. Since the conflicts are
> expected to be rare, the version would typically almost always match.
> That way, we can request operations from their indices ("remove item at
> index 42", "insert this item at index 10"): if the version matches, then
> the index is necessarily correct. Also, operations may not be "partially
> applied". The big drawback is that this "versioning" would need to be
> exposed to the clients of the API.

First, we cannot change the interface to external clients, such as MPRIS 
clients or HTTP remote controls.

And then, even if we could, if the playlist is preparsing a directory, it will 
keep changing, so the user would be effectively unable to react fast enough to 
make any changes. I don't think a transactional model can work well here.

Note that input items are already reference counted, so the problem of 
asynchronous deletion is nonexistent. You can always treat a move as a 
deletion and an insertion. If the deletion has already occured asynchronously, 
then skip that step and insert the item back into the playlist.


What you cannot know is if the user meant to move the item at a certain 
offset, after a certain other item, before a certain third item, or whatever. 
You might provide separate APIs for different cases, but the drag & drop 
action cannot make the distinction.

-- 
Rémi Denis-Courmont
http://www.remlab.net/