[vlc-devel] RFC: refurbishing the configuration manager

[Samuel Hocevar]

  I would like to change a few things in the way config variables
work. I'd especially like Gildas's opinion since he did most of the
hard work in there and maybe I missed a few obvious things.

  Currently, variables are module-based, and their value is stored in
the module structure, which is nice for a few reasons:

 - modules can add all the variables they want
 - it makes it easy to build the preferences panel

  There are a few annoying drawbacks though:

 - vlc itself needs to be a module for common variables, which was
   done easily but does not make much sense.
 - we need an ugly hack for the help module (see libvlc.c)
 - two modules cannot share the same variable name
 - to get a variable value or set it, we need to look into all modules
   and do a lot of string comparisons (see config_FindConfig)

  We have had these issues since the beginning and we could live with
them. However I have a more important problem now: the mozilla plugin
passes data to libvlc using configuration variables, but there is only
one module bank shared by all the libvlc instances. Which leads to
obvious multithread issues. So something definitely has to be done, and
my idea is to solve a few other issues meanwhile.

  Things I could think of:

 - variables should be stored in the object using them, or one of its
   parents; for instance "fast-mutex" should be in p_libvlc, but "loop"
   could have different values for each p_vlc, and "width" or "height"
   have a meaning in all video output objects
 - if module foo and module bar define the variable "quux", we can
   differenciate them by using "foo::quux" or "bar::quux"; exact
   behaviour when setting or getting the value is yet to be decided
 - if object 12 and object 42 use the variable "wok" we can
   differenciate them by using "12::wok" and "42::wok" or maybe
   something else to be decided
 - we should be able to create new variables for any object that suits
   us, and not restrain to the module discovery step
 - we should be able to dynamically add items to list variables; for
   instance the discovery of a new audio device adds a string to the
   "audio-device" variable; removal should be possible as well
 - range variables such as "volume" should be checked for validity

  Here are a few function prototypes to give you an idea of what I
intend to do:

    /* New stuff */
    void var_New( vlc_object_t *, char *psz_name, int i_type );
    void var_SetScope( vlc_object_t *, char *psz_name, int i_scope );
    void var_Delete( vlc_object_t *, char *psz_name );

    /* i_type could be one of STRING, BOOLEAN, INT, INT_FROM_LIST, FLOAT,
     * FLOAT_FROM_LIST, STRING_FROM_LIST, but also derivate types such as FILE,
     * FONT, TIMESTAMP... */

    /* i_scope could be one of OBJECT_LOCAL, VLC_LOCAL, GLOBAL... */

    void var_SetRange( vlc_object_t *, char *psz_name, s64 i_min, s64 i_max );
    void var_AddChoice( vlc_object_t *, char *psz_name, char *psz_choice );

    /* Functions that we already have (could be merged into one function
     * and several macros) */
    int var_SetInt( vlc_object_t *, char *psz_name, s64 i_value );
    int var_SetString( vlc_object_t *, char *psz_name, char *psz_value );
    int var_SetFloat( vlc_object_t *, char *psz_name, float f_value );

    s64 var_GetInt( vlc_object_t *, char *psz_name );
    char * var_GetString( vlc_object_t *, char *psz_name );
    float var_GetFloat( vlc_object_t *, char *psz_name );

  As for the implementation, hashtables seem mandatory to me. A variable
would be looked for in the current object, then its parent, then its
parent, and so on until it is found, and the more strcmp we can avoid the
better.

  Any comments so far? The preferences panel layout and the config
file will have to be rethought a bit, which I'll try to develop in a
subsequent post.

Regards,
-- 
Sam.
-- 
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>