<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7036.0">
<TITLE>Recommendation: Configuration.c update to allow reuse of command-line parser</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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 */"</FONT></P>
<P><FONT SIZE=2 FACE="Arial">To " /* Close the longopts and shortopts structures */"</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">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 */").</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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. </FONT></P>
<P><FONT SIZE=2 FACE="Arial">(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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">A concrete example:</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">In the section starting at line 1424: </FONT>
<BR><FONT SIZE=2 FACE="Arial"> /* A long option has been recognized */</FONT>
<BR><FONT SIZE=2 FACE="Arial"> if( i_cmd == 0 )</FONT>
<BR><FONT SIZE=2 FACE="Arial"> {</FONT>
<BR><FONT SIZE=2 FACE="Arial"> module_config_t *p_conf;</FONT>
<BR><FONT SIZE=2 FACE="Arial"> char *psz_name = (char *)p_longopts[i_index].name;</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial"> /* Check if we deal with a --nofoo or --no-foo long option */</FONT>
<BR><FONT SIZE=2 FACE="Arial"> if( flag ) psz_name += psz_name[2] == '-' ? 3 : 2;</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial"> /* Store the configuration option */</FONT>
<BR><FONT SIZE=2 FACE="Arial"> p_conf = config_FindConfig( p_this, psz_name );</FONT>
<BR><FONT SIZE=2 FACE="Arial">Add a test:</FONT>
<BR><FONT SIZE=2 FACE="Arial">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 */</FONT></P>
<P><FONT SIZE=2 FACE="Arial"> b_SetOTF = VLC__TRUE else b_setOTF = VLC_FALSE;</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Then the case statements immediately below get adjusted, for example:</FONT>
<BR><FONT SIZE=2 FACE="Arial"> case CONFIG_ITEM_INTEGER:</FONT>
<BR><FONT SIZE=2 FACE="Arial"> config_PutInt( p_this, psz_name, strtol(optarg, 0, 0));</FONT>
<BR><FONT SIZE=2 FACE="Arial"> break;</FONT>
<BR><FONT SIZE=2 FACE="Arial">Becomes:</FONT>
<BR><FONT SIZE=2 FACE="Arial"> case CONFIG_ITEM_INTEGER:</FONT>
<BR><FONT SIZE=2 FACE="Arial"> if (!b_SetOTF) config_PutInt( p_this, psz_name, strtol(optarg, 0, 0)) /* not on-the-fly -- a true startup parameter */</FONT></P>
<P><FONT SIZE=2 FACE="Arial"> else var_Set( p_input, strtol(optarg, 0, 0)); /* an on-the-fly variable */</FONT>
<BR><FONT SIZE=2 FACE="Arial"> break;</FONT>
</P>
<BR>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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. </FONT></P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">Thoughts/comments?</FONT>
</P>
</BODY>
</HTML>