Deprecating the VLM

[Pierre Ynard]

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

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

I'm surprised that this got little direct response. JB, Romain,
everybody else? What do you think, is that okay with you? I've submitted
a patch kind of meaning to enact this.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."