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

[Arpi]

Hi,

(pre-note: Andriy please don't offend Albeu, he seems to understand the
actual problems and solutions better than you...)

Ok I guess we want to much from the config api.
Actually wanting _a_ config api is alreayd too much.
Better separate it to layers, like the rest of teh code
(stream/demuxer/decoder/filter/ao/vo for example).

the layers may depend only on eachother.

imho the first layer should be a very lowlevel one, as all core libs
will depend on it. ye syou read it right, i said depends.
and even if you're saying no core dependency on config layer you still
defien structs and parameters inside core plugins so you lie :)

ok, back to the reality. let's define things:

config layer 0 (any better name?):
==================================
It's actually only a concept (==documentation) and 2 structs. No code.
(why are you surprised? :))

This is teh only layer on which teh core libs may depend.
This layer is responsible to tell the library user about teh available
options/parameters and their type, valid range. In Albeu's terminology it
exports the C-types.

One of the structs is the good old (with possible changes to make it better
for g2) struct config, aka config_t etc. So that one which you use to define
the possible options.

The other struct is a very simple struct to keep all info we want to know
about a module/plugin/layer. It's inspired by Andriy's common generalized
plugin_info thingie. While his idea is basically good, he wanted to
generalize the whole instances types (like vf_instance_t), afair.
So we could define a common structure to keep the pointers of config_t
struct (and related data: pointer to default values struct and struxt size)
and as a bonus, it could keep:
- type of the module (like: core, stream, demux, vd, ad, vf, af, ao, vo etc)
- (short) name of the module
- plugin filename (NULL for core and built-in/compiled-in modules)
  (in first draft i wanted filename to be computable from type+shortname,
  like type==vf + name==scale -> filename=vf_scale.so, but then i find
  several nice uses of different plugin names, like multiple versions of the
  same plugin co-exists, etc)
- credits related stuff (maintainer and author name/email/url/whatever)
- long (one line?) description (for GUIs and automatic -help screens)

Then redesign the current core APIs to base the vf_info_t etc on these structs.
Some APIs already have some such info_t structs, so it's easier for them.

Each core library should have an array of its built-in (static) modules,
and a separate struct describing itself (the library may have "global"
parameters, which belongs to the library itself (to control how to fins/
insert plugins or whatever) not to one of its specific plugin!
for example, for demuxer layer you have parameters to control the
autodetection process (extensionbased, contentbased, forced demuxer, list of
preferred ones etc), other example is stream layer's -cache parameter)

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

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.

also there should be a function to get plugin_info of one named plugin.
it could also use the cache, or just dlopen() that plugin.
this function could be used by CLI's what directly name the plugin to load
(like -vop foobar=1:2:3 means that we should try to load vf_foobar.so)

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)).

it should also implement the opposite, ie C-type -> string conversion, for
config file saving etc.

=====

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.

=====

to be continued... :)


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu