[vlc-devel] [PATCH] plugins: do not capture set of null-capability modules

[Lyndon Brown]

On Sun, 2020-09-27 at 09:28 +0300, Rémi Denis-Courmont wrote:
> Le lauantaina 26. syyskuuta 2020, 23.28.03 EEST Lyndon Brown a écrit
> :
> > On Sat, 2020-09-26 at 22:10 +0300, Rémi Denis-Courmont wrote:
> > The "store" function indeed only registers a module into a
> > capability
> > list. I see absolutely no useful purpose to capturing null/none/no
> > capability modules in doing this.
> 
> Not having to add a gratuitious special case that makes the code
> needlessly 
> complex is one. Listing by capabilities is another.

 - It's a very trivial condition check, with a thorough explanation
attached, ignoring the modules at their entry point into the database,
hardly making things complex; Furthermore having this check avoids
having to place other such checks in various other places to
filter/ignore them.
 - We avoid wasting memory keeping a record of what we simply don't
need a record of.
 - We avoid any theoretical bugs of "none" getting submitted as a cap-
list request returning a list of modules that the caller did not intend
to fetch.
 - I maintain that we have no legitimate interest at all in listing
anywhere these artefacts of plugin descriptor limitations. (Unless for
development purposes to locate where they are used, which we can
accomplish easily enough otherwise). Users certainly have no interest
in them. They simply shouldn't exist in a perfect system, and we should
hide them.

We can always drop this little check later if/when we provide a proper
means for plugin labels to be captured without the existing hack. It's
not certain that this will ever be done though (not least because it's
not been discussed), because most plugins don't need such labels, and
so it would be a little wasteful to provide for them in all plugin
objects. Until then, the existing "hack" is the only mechanism provided
for creating such labels, and we should ensure we ignore the modules
that result from it until we are able to eliminate them.

> And the real problem is that we should not force plugins to create a
> module if 
> they don't need one.

Agreed. But again, that can always come later and we can drop this
condition check then, and again, what certainty do we have that we will
ever reach that ideal of having eliminated them, since allowing labels
to be stored in the plugin object instead has the drawback of a lot of
waste since few plugins need it.