[MPlayer-dev-eng] Re: stupid option handling.. again???

[Balatoni Denes]

Hi!

It is clear that I don't know the config code at all - feel free to flame 
(better not:)) - but than I misunderstood Albeau. 
So if module is dlopend, there is no way to let mplayer know what options
that module supports. In this case each module could have  a function
that returns a pointer to its config structure - and than the module
doesn't depend on mplayer, but mplayer depends on features of the module.

modules dlopened is nice for at least 2 reasons imho: 
- you can delete any plugin you
don't need without recompiling and/or editing different files.
- third parties can make filters without getting flamed here all day (i don't 
whether there would be such 3rd parties, but still)

Of course all of these could be done through patches, which you have to 
maintain, etc. 

bye
Denes


> > >There is really no advantage. Again f we use registering then the
> > >register function (and all his deps) have to be linked in. If we just
> > >export a var the host app can chose what to do.
> >
> >     Why linked??? Register function is in main filters file (vf.c for
> > example) only! You can link your filter/codec later with dlopen() and
> > get all config structure for using by Gui on the fly! Your current
> > solution never allows it!
>
> I know that registering is needed if you dlopen some stuff. Again i know
> the advantages of registering (i wrote this registering stuff after all)
> but we experienced some problem with that. Registering is ok in the host
> app (here mplayer.c mencoder.c) others must export options list and not
> call the register function themself.