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

[D Richard Felker III]

On Wed, Jan 21, 2004 at 12:01:28AM +0200, Fre_ax wrote:
> > 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.
> So lets rename it to "data layer" and add seperate directory types for
> config data
> and playlists.

Config does NOT fit into nice little directories like you imagine. You
have little understanding of the config requirements it seems.

> I dont set the rules, by all means code at Gui directory could register
> these playlist directories.
> 
> > Interesting but this has nothing to do with the config system as we
> > know it.
> Yes i have realized that this is more about providing from place to place.
> 
> > 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.
> True but who says the command line interface would need to open this playlist
> directory and activate(generate entries in side the directory) this code
> at all?Of course these directories wouldnt even exist if user wants no guis.
> So you think its nicer to have tens and tens of options without grouping
> them atall ?

No, if you'd read any of the previous material on the config layer
you'd notice that it's all associated with instances of something, not
horrible globals like in G1.

> Yes, defined data types will define the "look" of UIs(including command line
> interface) but i dont see why this would be any kind of problem.
> 
> what do you mean by bloated exactly?

Dependency on an extra layer which isn't needed.

> > 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.
> Why would one want to keep this system and existing config system seperate ?

Because they don't belong together. Your directory "contains" config
data, so it can depend on the config layer, but there is no poing
whatsoever in the config layer depending on your directory stuff.

In fact when the config system was first discussed, one of the major
proposals that caused lots of flames was tightly integrating the
config system with gui/app/playlist stuff. The final decision was to
layer the config system, with the basic levels only defining data
structures and functions for manipulating config, and only putting the
gui/app stuff on the very top (and totally optional) layer.

> Adding new entry type that contains codecs_t or similar structures is no
> problem.
> 
> I do agree that its useless to implement this system if both dynamic and
> static configs(including relevant data communication with these structs)
> cannot be handled by extending this system.

What on earth is a dynamic config??

> I would however want to remind you that this system solves problems with DVB
> playlists, dynamic configuration and probably some other things.

It doesn't solve any problem with dynamic configuration. The difficult
end of dynamic configuration is the other end, the implementation.

As for DVB playlists, WTF is so special about them? How are they
different than any other playlist?

Rich