[vlc-devel] Playlist synchronization with multiple interfaces

[Romain Vimont]

Thank you for your feedbacks.

On Fri, Aug 24, 2018 at 05:28:37PM +0300, Rémi Denis-Courmont wrote:
> 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.

Even in VLC 4? (I don't say that it's a good idea to change them, I'm
just asking)

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

The items content will keep changing, but the items list would be
updated at most one (on subitems added). A change in items content would
not be considered as a write on the playlist (so the version would not
be incremented).

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

(Their side-effects might be different though. For example, if random
playback is enabled, if I move an item which was already played, it
should stay "played" (so it won't be randomly selected to be played one
more time), but if I remove it and add a new one, it will be considered
"not played yet". But it's a detail.)

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