tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libbozohttpd and lua

On Fri, Nov 06, 2009 at 09:55:28AM +0100, Martin Husemann wrote:
> On Fri, Nov 06, 2009 at 10:41:39AM +0200, Antti Kantee wrote:
> > And the "86 developers out of 100 prefer X to the leading brand"
> > subjective metric:
> > * do you consider the lua version significantly easier/better (keeping
> >   in mind you have to write the C glue and maintain it)
> Two more nits:
>  * how easy is it to add more command line options to the Lua code now
>    without touching any C code?

The lua code uses optparse.lua (kind of equivalent to getopt_long). Each option
is specified using one line of lua, e.g.

        opt.add_option{"-u", "--enable-users", action="store_true", 
dest="enableusers", help="--enable-users"}

(Options are parsed with the "options,args = opt.parse_args()" call)

Deciding what to do if an option is specified is 3 lines of lua:

        if options.enableusers then
                bozohttpd.set_pref(prefs, "enable users", "true")

In the C code, there is the corresponding "if name set to value, then
do this":

        if ((cp = bozo_get_pref(prefs, "enable users")) != NULL &&
            strcmp(cp, "true") == 0) {
                httpd->enable_users = 1;

Now I'm not saying everyone should do it like this, just that I find it
a very useful and clear way of organising option setting.

If the option code was already there in the C library, just waiting to
be called, then you'd just have to enable it with the 3 + 1 lines of
lua code above. But you could say very much the same about C.

>  * would you consider the Lua driver a kind of configuration file, thus
>    breaking the bozo paradigm?

No - the lua program decides what to do if the options are given, and then
calls code to do things. I'd consider the config file to be setting the
options. Two different things.


Home | Main Index | Thread Index | Old Index