the big modules changes

[Gildas Bazin]

On Wednesday 31 July 2002 21:17, Samuel Hocevar wrote:
> 
>    Unfortunately I can't think of an easier way to do it, even with the
> new stuff. Maybe we could have a chroma meta-plugin whose goal would be
> to try several chroma plugins and build a chroma chain? That would solve
> multilevel chroma transform issues at least.
> 
>    But that would still leave us with the problem of the video output
> module being initialized before the chroma is even looked at, preventing
> us to chose the best combination. Maybe the meta plugin could work in
> the background and provide such a service to the video output? I don't
> really know...

hmmm, I'd like to know something else which could make my life easier 
implementing this thing (when I'll have some time;).
I'd like to know if it could be reasonnable to assume that vlc will always 
probe for existing plugins at load-time only and that the user shouldn't 
remove or insert any new plugins during run-time (if he does we could just 
fail gracefully).

I'm saying that because we could then get rid of:

   module_bank.lock
and
    /* Lock all selected modules */
    p_tmp = p_first;
    while( p_tmp != NULL )
    {
        LockModule( p_tmp->p_module );
        p_tmp = p_tmp->p_next;
    }
in src/misc/modules.c in module_Need().
That would speed up module spawning quite a bit.

But that would also allow us to easily pass lists or sub-lists of available 
plugins to other modules requesting it (for instance video_output.c could 
know the list of available chroma plugins without having to actually load 
them into memory or take the module_bank.lock).

> 
>    Ah ah ah. As if I hadn't thought about that. Erm. Well, dummy, logger
> and null will probably go to a misc/ directory. As for SDL, the least
> ugly place would probably be in arch/, what do you think?
> 

A misc category would surely be usefull for things like the logger plugin, 
but for the others I guess it would be more sensible to split the plugins 
into different directories corresponding to their categories. Most of them 
are already splitted at the source file level anyway (like vout_dummy, 
input_dummy etc...). For instance vout_dummy.c would go into 
video/output/dummy, aout_dummy.c would go into audio/output/dummy and the 
comman part dummy.c could go into misc or maybe common.

I guess it will be a little bit more difficult to integrate this in the 
build system though.

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>