[MPlayer-G2-dev] Re: Data communication between demuxers and UIs

[Fre_ax]

> The config layer is ok as it is. Dynamic stuff should not be mixed
> with static variables. The config api should be extended to query for
> dynamic variables, but i dont have a good idea how to do so.

I see no reason why should there be different versions for static and dynamic
configurations mainly because there isnt just enough difference between them.

Heres my version:

Now the main reason why there should be directories is not
because config layer
would need them but because DVB playlists and generic playlists need it.
gmplayer currently implements its own playlist and i see no reason why would
all UIs need to have duplicated playlist implementations.
Even though UIs wouldnt need to use duplicated playlist code i see this
way far more cleaner. This system could also be modified to create directory
entries as user opens them(HTTP and FTP browsing).

This is how UIs might see this virtual filesystem:
- root
  - generic setup
    ...
 - DVB
   - options
      option1
      option2
   - playlist
      channel1
      channel2

 - playlist
    path to playlist file
 - playlist
    file1
    file2

 - demuxers
    ...

Each entry would contain flags that define things like: status locked,
disabled, hidden ...
dynamic/static config data providers(hosts) would also define
data types and limits for each entry so that developers wouldnt
need to make changes to UIs each time changes are made.

So since these entries can be updated i was thinking if this would be done
by adding timestamps(running counter would probably do) for each
directory and entry.
Example:
If DVB->options->option1 gets changed, not only option1's timestamp
gets updated but also DVB's and options's.
This way UIs would only need to compaire timestamps at the root
directory. This isnt perfect though as UIs need to keep track of all
entries timestamps. Or would it be better if only the root directory
would contain an timestamp and UI's would update everything if that changes ?

I also think that removing entries and directories shouldnt be allowed when
some directory works as a "dynamic-config"-mode as this way who ever provides
dynamic config data could define all reguired data types as global variables.

On the other hand, playlists would need linked lists to work with out any
silly limitations.
This can however be solved by just adding a new directory type.

So this would not only take care of current static/dynamic config stuff but
also give plenty of slack for future needs.

Also using multiple UIs at the same time
would be possible, since directories carry locks.

Another nice feature would be that config values could be fetched out from
cfg clients and saved into config files.

Now some code:

/* I recall seeing similar system in mplayer g1 */
#define CFG_ENTRY_NODE_INT 1
#define CFG_ENTRY_NODE_STRING 2
#define CFG_ENTRY_NODE_BOOLEAN 3 /* checkbox maybe ? */
/* other data types could include: selection lists, radio buttons,
   progress bars(i see no problem implementing this), ... */

struct cfg_entry_node_int{
  int value;
  int min_range, max_range;
};

struct cfg_entry_node_string{
  char *value; // this could be allocated to max_len so that UIs never need
to realloc
  int max_len;
  /* not really reguired as clients can ask hosts to verify correctness of
     values */
  char *allowed_chars; // 1 allowed, 0 not. size would be 256 of course
  // ...?
};

/* cfg_entry_node_int with ranges 0-1 could take care of this */
struct cfg_entry_node_boolean{
  char value;
};

struct cfg_entry_option{
  int type;
/* some info about this option for UIs.
  (could also be used by the command line interface) */
  char *info;
  union{
    struct cfg_entry_node_int int_d;
    struct cfg_entry_node_string string_d;
    struct cfg_entry_node_boolean boolean_d;
  };
};

struct cfg_entry;

struct cfg_entry_dir{
  char *name;
  struct cfg_entry *parent; /* could be cfg_entry_dir as well */
  llist *entries; // linked list filled with config_entry's
  pthread_mutex mutex; // or something similar
};

#define CFG_ENTRY_TYPE_OPTION 1
#define CFG_ENTRY_TYPE_DIR 2
// more types ?

#define CFG_ENTRY_FLAG_LOCKED 1 // read only for UI's
#define CFG_ENTRY_FLAG_HIDDEN 2 // hidden dir/option
#define CFG_ENTRY_FLAG_DISABLED 3 // dir/option not currently available

struct cfg_entry{
  int type;

/* UIs need to keep track of these and update if changed.
   Not very nice but i didnt come up with anything better...
   UIs can however easily check if updates have occurred since all parent
   directories will get their timestamps updated. Folowing the "path" will
   then   lead to the entry that has changed */
  unsigned int timestamp;
  int flags;

  union{
    struct cfg_entry_option option;
    struct cfg_entry_dir dir;
  };

};
#define CFG_OK 0
#define CFG_EINVAL 1
/* ...? */

/* gets filled by hosts */
struct cfg_host {
  struct cfg_entry *entry;
  /* UIs call this to do sanity checks. returns CFG_OK, CFG_EINVAL ...
   It might be smarter if clients never directly modify any of the values in
   cfg_entry_option since this might make hosts crazy as they loose their
   sane   values(assuming that they dont keep backups),
   so this callback could be used to actually set the values
  */

  int (*entry_set) (struct cfg_entry *entry, struct cfg_entry *new);
  // or:
  //int (*entry_changed) (struct cfg_entry *entry);
};

--Aapo Tahkola