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

Andriy N. Gritsenko andrej at lucky.net
Wed May 14 11:33:31 CEST 2003


    Hi, Arpi!

Sometime (on Wednesday, May 14 at  0:39) I've received something...
>config layer 0 (any better name?):
>==================================
>It's actually only a concept (==documentation) and 2 structs. No code.
>(why are you surprised? :))

    I'm not surprised at all. You just splitted all API to layers. It's
good and I wanted to make that later. I wrote all layers in one cfg.h
because I didn't want to create too many files, it's all. :)
    BTW, thank you, you've understood most of my thoughts.

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

Do you mean all *_instance_t must be thing for application only, not
unified?

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

    Fully agree with that. Only question - how application will import
these infos? We will implement some registering function or we will see
its just as arrays and let application integrate it all in own trees by
itself?

    Other question is how we would implement adding of options from
demux_core_info into common list of options? Why I asking that? If we
have only main config_t structure then it's a static array so we cannot
reallocate it. It's why I proposed to make a structure cfg_tree_t. Sure,
it's a structure for layer 2 only and it will be used for parsing and
searching, but it will be better than (re)allocate a memory for whole
main config_t thing, won't it?

    With the best wishes.
    Andriy.



More information about the MPlayer-G2-dev mailing list