[vlc-devel] [PATCH 00/14] Move VLM implementation to a module

[Pierre Ynard]

I would tend to agree with Rémi here: it doesn't make a whole lot sense
to me to move the VLM implementation to a module while keeping its core
API. It adds new layers of indirection, and doesn't accomplish much; it
doesn't change anything about my main issues with the VLM.

We've been arguing over proposed patchsets. I'd like if we just talked
about the VLM.

I think the VLM sucks. Reasons why:

- It's unwieldy and ugly.

- It uses an internal command line interface API, text-based in a
  pointless way as it hardly faces the user - in fact it favors
  anti-patterns to make it face the user.

- It uses an awkward, unwieldy custom message tree structure for output.

- Its design and place within the VLC core doesn't seem very sound:
  the fact that it was introduced as a proof-of-concept doesn't speak
  greatly here.

- It has technical shortcomings, for example it doesn't support
  playlists as input (#3510), so it won't even work with web radio
  streams presenting themselves as a trivial playlist of alternative
  servers. I presume this would be a by-product of not properly reusing
  or integrating with core subsystems such as playlists or players.

I also think the VLM is a nice feature as it does a decent job at
tackling some form of multiple-input management.

As it has been pointed out, there are several other ways to manage
multiple inputs:

- using several separate VLC instances, one per input
- using the LibVLC API, which supports this
- using current core APIs from interface or control modules

There are some features that legitimately call for single-instance
multiple inputs: we've mentioned VoD, the sout bridge... Regardless,
I believe that people also find value in having a multiple-input
management solution within a single VLC instance, as something that
falls somewhere on the bloat / Swiss Army knife spectrum.

The VLM offers that. Separate VLC instances don't work or are not what's
wanted; the LibVLC API doesn't work since, as it was pointed out, users
don't use LibVLC, only VLC; existing or dedicated interface modules
properly using available core APIs would theoretically work, but for
now, that's non-existent.

I'll say it again: I think it would make a lot of sense to favor this
latter approach in new work.

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.

In my mind that wouldn't be a decision that entails dismantling the
VLM. It would already have value in itself as a policy and signal,
to ourselves, but also to users: it could rightly point some of them
towards more appropriately using separate VLC instances, or OS task
scheduling services, instead of the VLM just because it's there. We can
(and have) discussed dismantling the VLM or parts of it, and that can be
a valid but separate matter.

The only in-tree users of the VLM API are the --vlm-conf parameter, the
Qt GUI and the lua bindings; with the lua CLI and the HTTP interface.
--vlm-conf and the CLI seem to me like appropriate ways to access the
VLM. I don't know how many people use the Qt dialog, and I wonder. As
for the web interface, it seems more like a way to expose stream outputs
than multiple input management; and nicely showcases the ways in which
the VLM sucks as described above.

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.

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