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

[D Richard Felker III]

On Tue, Jan 20, 2004 at 05:23:23AM +0200, Fre_ax wrote:
> > 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.

I see no reason playlists are a "config" item. Rather, a playlist is a
list of sources and configurations for playing them. Some users of the
mplayer-g2 core will want to have playlists, but for others it makes
no sense, or needs to be treated differently, so I'm opposed to
putting all kinds of playlist nonsense into the core.

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

Interesting but this has nothing to do with the config system as we
know it.

> 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 don't like this whole "directories" thing. It's windowsish, bloated,
and forces a particular system on the caller which won't be
appropriate for anything but gui players with playlists.

I see no reason why you couldn't build something like this on top of
the G2 architecture (including the existing config system) without
having to tie all this mess in at a low level where it would be
annoying to users who don't want it.

Rich