[MPlayer-G2-dev] g2 config - restart...

[D Richard Felker III]

On Wed, May 14, 2003 at 12:14:53AM +0200, Arpi wrote:
> config layer 0 (any better name?):
> ==================================
> It's actually only a concept (==documentation) and 2 structs. No code.
> (why are you surprised? :))

:))

> so what about libdemux exporting plugin_info* demux_core_info and
> plugin_info** demux_modules_info, and so on for every library.

You mentioned earlier that perhaps "module" is a better name than
"plugin". I agree there!

> config layer 1:  core libs configuration helper functions
> ===============
> 
> you may ask now, what about the dinamic (dlopen'ed) plugins?
> we could write a helper function (probably as part of the config layer core)
> to scan a whole plugin dir(-structure) and read the above plugin_info
> structure from each plugin. it could include some kind of cache, as Michael
> proposed. if the UI (it may be CLI's -vf help kind of option, or GUI's
> dropdown combobox) needs the list of available modules/plugins, it can
> additionally call this function to get info about dinamic (optional) plugins.
> it's fully optional, UI only calls it if it wants, no one (esp. not the
> config parser!) will call that automatically at startup.

Yes, ESPECIALLY not the config parser! :)

> layer 2 will handle the lowlevel parsing, ie. string -> C-type conversions,
> =========================================
> based on config_t structs. it will provide simple functions to parse options
> from sing and return teh dinamically allocated (cloned from static
> 'prototype' and the parsed options then overwrite defaults)
> ((there could be an optional prototype arg of the func, so UI can override
> the static prototype by some other, like configuration inherited from upper
> level, aka configtree/playtree)).

Yes, I like this idea a lot. It seems to simplify the whole playtree
logic greatly.

> Ok now we have everything for a lowlevel API, so if we have parameters (in
> string format!!!) for various plugins, modules (like vo_subdev, vf args, etc)
> we can do this while building the framework (path of layers) we'll use:
>  - retrieve layer/module/plugin's plugin_info (see layer1's 2nd func)
>  - call layer2's parser func to transfer string to config structure, also do
>    error/syntax checking and handle fatal errors (fail-out)
>  - call the layer/module/plugin open() with the config structure as parameter
> repeat this for every layer/module initialization.

Nice and clean.

Rich