Re: Data communication between demuxers and UIs

    Hi, Attila Kinali!

Sometime (on Friday, January 16 at 18:22) I've received something...
>On Fri, 16 Jan 2004 15:48:02 +0200
>"Andriy N. Gritsenko" <[email protected]> wrote:

>> So I've proposed the idea then:
>> 1) node which could have dinamic variables list provides that list
>>   (template) as a variable with a special type to UI;
>> 2) UI calls that node for init;
>> 3) node changes own config structure as it needs;
>> 4) UI rechecks node's config structure.
>> 
>> I think it must be very simple. Tell me if I was dumb in that.


>Yes, it's simple and that is the problem with it, it's too simple.

>1) How do you represent the variables, their types and ranges ?

    Of course, as usual, via fields of config_t for each variable. All
variables are available as NULL-terminated list, as usual but it must be
not static structure for module but dynamic list instead.

>2) How do you avoid inconsistencies (possible sig11) when the node 
>   changes the available variables and their ranges.

    Each time when UI wants change (select, etc.) something in current
tree of chains then it will just build own windows etc. based on current
tree of variables. So we agree to don't hash all inside of UI and it's
all. :)
    If you mean the case when current value is outside of new range then
I think filter/codec/etc. anyway will not get that current value from
previous filter/codec/etc. but it may do only UI.

>3) How do you signal changed values. Rechecking all structures
>   for changes isn't a good idea.

    Let's see - when values may be changed? Only when UI sends some
signal to node - play new file, insert new filter, etc. While you play
the same file it's silly to change anything by node itself. Then UI will
anyway recheck all as I said before in 4). If UI doesn't want change
anything then it'll just leave all as before. If UI wants then it'll
change it and send some request to node to accept changes.

    With best wishes.
    Andriy.