Re: [PATCH 1/2] registry: add grl_plugin_registry_load_default() method

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Tue, 2011-06-28 at 15:59 +0100, lionel g landwerlin linux intel com
wrote:
> From: Lionel Landwerlin <lionel g landwerlin linux intel com>
> 
> The purpose of this new method is to provide an helper to load a given
> set of plugins using the command line or an environment variable. It
> is useful for debugging.
> 


I like the idea of having a way of restricting the plugins that
application is going to see. I thought to do it several times too.

But I don't like very much the way of doing it. Adding a new API to do
it doesn't seem the best way to go.

IMHO, if user restricts the list of plugins to see by the application
(either with the envvar or with a parameter to application), then when
application tries to load all plugins or a specific plugin, through
grl_plugin_registry_load_all(), grl_plugin_registry_load_directory() or
grl_plugin_registry_load_by_id() [1], only those plugins in the set
should be visible. Thus, it is easier to ban a specific plugin from
being using in a specific application.

If you have a different API for this, then you must rely on your
application using _load_default() instead of _load_all() to do the job.
If application uses _load_all(), then to do the job you would need to
remove physically the banned plugin.

Summing up, let's define an envvar/parameter with the list of plugins to
be used, but let's use that list in the current API
(grl_plugin_registry_load_directory(), grl_plugin_registry_load_all()
and grl_plugin_registry_load_by_id()), and not adding new api.

	J.A.

[1] Only grl_plugin_registry_load() should not use that list, because
this function is to intended to load a specific .so sited in any place,
even not in the standard places of plugins. Actually, this function is
not restricted by any ennvar.