[vlc-devel] [RFC] custom module capabilities

[Lyndon Brown]

This is all to-be-merged (in-tree) stuff though right? So could you not
just easily incorporate addition of a new core enum entry and bump of
the plugin API in the patch sets?

The current solution I implemented does, as I said, allow for custom
string based capabilities to be used just as currently, alongside the
main system using an enum. But ideally it would be neater if such
support were dropped and only the enum was used. Is tweaking the enum
in your work sufficiently problematic as to justify retaining this in
an enum solution?

I do appreciate the agility of the existing string solution, though I'm
not a fan of it :D

Is there any desire to keep such custom string capability support for
the benefit of 3rd-party out-of-tree modules? I.e. if one such module
needs to create a new capability for other such out-of-tree modules to
provide for it. Is supporting this a real concern?

Regarding display in interfaces and such, a simple translation
mechanism is provided in the solution for this.

There's no particular problem resulting from the efficiency of the
current design, I just saw opportunity to do better. As I said in the
reply just sent to what Remi said, one efficiency improvement that the
enum solution offers is the ability to fetch the set of modules for a
given capability as quickly as indexing into an array, avoiding
entirely binary/hash string based searches. It thus helps optimise all
of the code paths setting up playback of media and such. (The plugin
database already stores lists sorted by score and capability, but using
the enum as a numeric array index we grab the right list directly,
rather than searching for it).


On Thu, 2020-09-03 at 18:47 +0200, Alexandre Janniaux wrote:
> In the current tree, "opengl interop" are not provided by the
> core but by modules. In ML and private branch, we also have
> "opengl filter" which doesn't exist in the core, or I also
> had "wayland buffer backend" to extend the current wayland
> module.
> 
> In general, having string as module capabilities gives quite
> some agility that I, personnally, would like to keep.
> 
> In addition, it gives free debugging string for what is loaded
> and what must be shown on the interface.
> 
> I'd prefer that you create defines in the core that might be
> used in modules instead for the catching mistake part.
> 
> About efficiency, in which case is it a problem currently?
> If there is, we could implement a quicker lookup with an
> hash based function instead.