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

[Rémi Denis-Courmont]

Le keskiviikkona 16. syyskuuta 2020, 0.26.57 EEST Alexandre Janniaux a écrit :
> On Tue, Sep 15, 2020 at 09:10:16PM +0300, Rémi Denis-Courmont wrote:
> > Le tiistaina 15. syyskuuta 2020, 20.37.32 EEST Romain Vimont a écrit :
> > Converting VLM or parts of it into an interface module? Fixing bugs?
> > Removing useless code? great. Adding a new module type? no thanks.
> 
> While I agree that an interface would be an improvement of such
> integration of feature outside vlccore, I'm not sure putting
> everything behind interface is a good help with regards to how
> this rework should go.

Why do you even want to rework VLM? VLM exists because some people use the VLM 
syntax to set up streaming pipelines. There is very little room for making 
meaningful changes without breaking the syntax or the semantics.

Obviously, you can fix bugs. You can remove what little unused bits and pieces 
are left. You can move the parser to an interface (or into the RC interface), 
and/or rewrite it into a safer and more suitable language than C, such as 
flex+bison. As I've noted before, I do not recommend spending much time on 
that, but that's nothing more than a recommendation.

However, what do you achieve by moving the entirety of the VLM code to a new 
ad-hoc module? You end up having to add a whole new set of wrappers, and 
export more functions (including at least one that is deprecated and known 
broken on non-Linux). You're just making the code bigger and more complex 
rather than smaller and simpler...

> VLM definitively has an interface capability so as to let the
> user enable it, and be able to initialize at startup, but I
> don't think Romain is there yet in its current work. We should
> probably discuss on how the VLM core can be interacted rather
> than where to move the code first.

I'm not sure what you think VLM is. At this point it's really just a textual 
command parser to demonstrate multiple inputs. Its inventor called it a 
nothing but proof-of-concept for multiple inputs - at a time when VLS was 
still a thing, and could do multiple inputs that VLC could not.

OK, that and a completely broken useless and unused calendaring function which 
treats every months as 30 days and every days as 24 hours.

If you want to manage inputs programmatically rather than textually (e.g. to 
hook up a GUI), you're most certainly better off ignoring VLM and going 
straight to the vlc_player API.

> If we move VLM behind an interface label, other interfaces must
> be able to access the VLM entrypoints

This is very questionable. Now that the guts of VLM have already been replaced 
with vlc_player, VLM is essentially a text (input) parser over vlc_player with 
some poorly defined text (output) formatting. For GUI programming purpose, I 
don't see the point in VLM. It's just needlessly painful to program things via 
text rather than function calls.

So there's not a lot of reasons for even accessing the parser entrypoints. 
They're needed to parse the configuration file, and then they're also needed to 
accept live commands via some RPC mechanism (currently clumsily handled by the 
TCP socket mode of the RC interface), but I don't see what else?

But if there is a reason to keep the VLM entrypoints in the plugin API for 
more than one interfaces to use, then that's all the more reasons to keep it 
in the core, and not move it artificially into an ad-hoc module.

-- 
Rémi Denis-Courmont
http://www.remlab.net/