[vlc-devel] Playlist synchronization with multiple interfaces
rom1v at videolabs.io
Fri Aug 24 16:51:50 CEST 2018
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
> 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
> 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.
More information about the vlc-devel