[vlc-devel] [RFC] custom module capabilities

[Alexandre Janniaux]

Hi,

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.

Regards,
--
Alexandre Janniaux
Videolabs

On Thu, Sep 03, 2020 at 04:49:20PM +0100, Lyndon Brown wrote:
> I'm currently working hard on rebasing a big chunk of work (~600
> commits) that I'd produced early last year but never got around to
> submitting until now.
>
> I have a question that I might as well ask now.
>
> One set of patches switches capabilities over to be enum based. (For
> which there are advantages such as efficiency and catching mistakes).
>
> I made an assumption at the time that there might be a valid argument
> for keeping the ability for modules to use custom capabilities, which
> would require that a string based mechanism remain alongside the new
> enum based stuff. I thus built the solution accordingly.
>
> It would obviously be neater of course if it were not necessary.
>
> It would be helpful to get a concrete answer as to the need of such
> "custom" string based capabilities. Did I do the right thing in keeping
> this available? Or can I scrap it, going full enum?
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel