[vlc-devel] Re: RFC: refurbishing the configuration manager

[Gildas Bazin]

On Monday 14 October 2002 19:41, Samuel Hocevar wrote:
> 
>    Why do you absolutely want to see randomness here? These configuration
> options changes can be triggered by the user as well. Of course if some
> evil programmer wants to hose things and add random changes here and
> there there is no way we can prevent it, but even now we cannot prevent
> a badly coded part of vlc from unloading modules at random. We just need
> to discipline ourselves and remember that the user exists.
...
>    Again, it won't be random. If the user clicks on "detect soundcards"
> she'll be expecting something to change in the preferences panel. I'd
> even expect her to be lost if nothing has changed.

Ah, I'm glad to see you acknowledge that run-time variables must never 
remove control from the user. I'm also glad you realize that there needs to 
be a kind of registration of variables at initialization time, even for 
run-time ones (remember, you propose to register a hook in the preferences 
interface).
I'm still a little bit worried with a few things though.

You seem to prone good useage of run-time variables but your API IMHO is an 
incitation to misuse for programmers (evil or not) because it doesn't 
provide a way to setup the hook (in the preferences interface) you are 
talking about.
This is one of the reasons why I proposed an API to create 
initialization-time variables (which you will be able to save) and another 
one for run-time variables (which you won't be able to save). This is a 
little bit more restrictive than what you want to do, but has the advantage 
to be very clear to the programmer and also to do the initialisation-time 
registration implicitly (because only initialization-time variables can be 
saved).

But I said it was only one of the reasons, the other one is quite different.
I would like to know how you plan to save the config file.
Right now the configuration file is saved on a module per module basis.
This is very practical because it allows you to save a new configuration for 
a module without loosing the configuration of modules you have temporarily 
removed (i.e when you save the config for a module, the config for all the 
other modules are just copied over from the old config file).
It is also practical because it completely rewrites the config for the 
module you save, which means that any deprecated options will get removed 
automatically and your config file won't get clubbered too much.

Now if you want to be able to save some run-time variables, you can't do 
this anymore. Why ? will you say. Well because when the user decides to 
save the config for one module, some run-time variables will likely not 
have been created yet. If the user had been able to save them earlier (by 
clicking on "soundcard autodetect" and "save" for instance), they will then 
be overwritten and lost! Too bad for the user!

> 
> > I think that when you will understand that, we'll be able to come to an 
> > agreement ;)
> 
>    Don't worry, I won't insist for long.. it's not that a big deal to
> me, but I'm really curious why you keep talking about randomness. All
> the examples I gave were user-triggered :)

I'm really sorry, but you still haven't convinced me that run-time variables 
are good candidates for being saved in a config file. And by the way, it's 
certainly not your example that has convinced me since I fail to see why a 
"soundcard autodetect" couldn't be done at initialization time and without 
user intervention (unless of course you would like to be able to support 
hot-pluggable systems ;) but even in this case, why not just provide a 
"reload module" button :))

Sam, you will have to try harder :)

--
Gildas
-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>