[vlc-devel] Recommendation: Configuration.c update to allow reuse of command-line parser

[Mark Moriarty]

I'm trying to understand if it is feasible to rework the function
config_LoadCmdLine to make it reuseable, as a way to also handle dynamic
control of VLC.

1.  Split off the module and options discovery (generation of list,
longopts, shortopts) into a standalone function, run at VLC startup, so that
the list of possible things to work with is separate from parsing the actual
command being generated.  Store these items long-term (persistent), so that
they can be reused.  I'm talking about the code from about 1272 - 1414 of
the current configuration.c, going from "    /* List all modules */"
To "    /* Close the longopts and shortopts structures */"

2.  Split off the options discovery/setting code into a standalone
procedure.  Pretty much the code from lines 1416, "* Parse the command line
options",  to line 1533, (just before "    /* Free allocated resources */").

The new function, (2), would include a variable to allow designation of the
calling function type.  A "1" could indicate console, in which case the
current print statements can be used as-is.  A "2" could indicate anything
else, so that the print statements would be replaced with a returned list of
error/warning messages.  The calling function would be responsible for
acting on the returned list of error/warning/whatever messages.  

(2) would pretty much perform the current processing, plus it would do a
check to see if there is already a pre-existing variable "tacked-up",
matching the particular longopt or shortopt identified.  If there is a
variable in-place, that means the longopt/shortopt is an on-the-fly
parameter, the new function would set that variable.

A concrete example:

In the section starting at line 1424:  
        /* A long option has been recognized */
        if( i_cmd == 0 )
        {
            module_config_t *p_conf;
            char *psz_name = (char *)p_longopts[i_index].name;

            /* Check if we deal with a --nofoo or --no-foo long option */
            if( flag ) psz_name += psz_name[2] == '-' ? 3 : 2;

            /* Store the configuration option */
            p_conf = config_FindConfig( p_this, psz_name );
Add a test:
If ( var_exist(p_input, psz_name) )   /*I know it's the wrong call --
there's one that lets you check for a var existance */
   b_SetOTF = VLC__TRUE else b_setOTF = VLC_FALSE;

Then the case statements immediately below get adjusted, for example:
            case CONFIG_ITEM_INTEGER:
                config_PutInt( p_this, psz_name, strtol(optarg, 0, 0));
                break;
Becomes:
             case CONFIG_ITEM_INTEGER:
                if (!b_SetOTF) config_PutInt( p_this, psz_name,
strtol(optarg, 0, 0)) /* not on-the-fly -- a true startup parameter */
                   else var_Set( p_input, strtol(optarg, 0, 0)); /* an
on-the-fly variable */
                break;


If I launch VLC with logo, for example, the "--logo-x=100"  should be
processed equally well for either the initial command-line startup or for an
OTF change.

The above would allow for a socket based interface to at least handle a
multi-parameter option string ("--logo-x=100 --logo-y=50"), as long as the
input string on the socket uses the same format as allowed on the current
command-line.  It would allow for general user interfaces to get rid of the
"gludge" work of having to independently check for OTF parameters -- just
ship the string to the new parser function to handle that.  It would provide
commonality of the command syntax between console startup and telnet-type
socket commands.

This absolutely doesn't require that all options be on the fly -- if a
particular module hasn't created a control variable, with callback, then
b_SetOTF will be FALSE, no harm done.  

The above doesn't mean that a user interface cannot have unique
options/capabilities/commands, above and beyond the basic shortcuts/options.
You just pass the input string to the parser first, to handle the "gludge"
settings, then can independently process the string if there are any
special/unique commands that you need to look at.

A recognize that, for example, perhaps INPUT might not be the right object
to attach the variables against, but there should be some top-level
structure where shortcuts could be placed, and only placed if they are live
"OTF" variables.  I only use INPUT because that's where the marq and logo
OTFs are, at present.

Thoughts/comments?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20041110/7ac4ad5a/attachment.html>