[vlc-devel] Deprecating the VLM

[Alexandre Janniaux]

Hi,

On Mon, Sep 21, 2020 at 12:00:28PM +0200, Jean-Baptiste Kempf wrote:
> On 21/09/2020 03:20, Pierre Ynard via vlc-devel wrote:
>
>         And I would like to propose deprecating the VLM. I would like to
>         propose that we agree to stop development of it or around it: no more
>         new features, no new APIs or exported symbols, no more exposing it
>         through new interfaces (for example #2887), and no new developments
>         based on it or integrating around it. We can print a deprecation
>         notice upon loading, and mark the API calls as deprecated. And then
>         we can also stop wasting time and efforts on patchsets and arguments
>         about VLM developments.
>
> Deprecating without an equivalent solution is really weird.
>
>         So in addition to deprecating the VLM, I would also like to ask
>         whether anyone is opposed to the principle of 1/ migrating existing
>         multiple-input management in interfaces away from transparent VLM
>         exposure to proper core APIs and UX, and 2/ migrating features
>         requiring single-instance multiple inputs away from the VLM to
>         dedicated control interfaces, or maybe possibly dedicated LibVLC
>         applications. This would look to me like a sound alternative and way
>         to go, even if nobody puts resources into it right now. This wouldn't
>         preclude ongoing additional work on core subsystems to accommodate it.
>
> This is exactly what was tried:
>
> - new player + playlist to avoid input/player duplication (mostly done)
>
> - move VLM file parsing to a new module (whatever the type) and have the player
> /playlist handle the features required, so that that modules does only parsing
> + spawning of various players.
>
> - have the VLM module understand most of the VLM file syntax.
>
> So I'm not sure in what way what you are suggesting is different from the
> current approach.
>
> As for dedicated libVLC application, I already explained why I was against
> this.

I was thinking whether my point really makes sense but in the
end it's the same as J-B:

I don't think deprecation without alternative is a good tool.
Users wanting the feature will be forced to use it and those
who would need to fix it/improve it in a raisonable direction
would probably send patches for this. (though with the state
of VLM, we could expect nobody would).

Either we remove it as a whole or we clean up and split the
PoC into where it belongs to keep the features, and since we
are investing time to clean up and split it, we just need to
do deprecation or just plain removal after the split, just
like planned by Romain and J-B.

I don't think there's much to discuss on this side, everybody
without exception agrees that VLM in its current state is crap
but has nice or unavoidable features.

However, according to the previous discussion on playlists,
VLM modules and others, we still have much margin to organize
the design at the big picture level and implementation level
before committing to it and actually develop it, as well as
the exact scope of features we want to have.

> And then we can also stop wasting time and efforts on patchsets
> and arguments about VLM developments.

This should be matching what you've expected in your message,
better than a pure deprecation and removal approach that we
don't want at Videolabs and didn't want in previous workshops
already.

Regards,
--
Alexandre Janniaux
Videolabs