[spambayes-dev] proposal for more uniform option setting from thecommand line

[Skip Montanaro]

    >> -o Storage:persistent_storage_file:~/.hammiedb
    >> 
    >> or
    >> 
    >> --option=Storage:persistent_storage_file:~/.hammiedb

    Kenny> This sounds useful for those doing testing with various options,
    Kenny> and I'm all for it from that standpoint.  However, I'm not sure
    Kenny> how useful it would be for the average user.

Correct.  However, the average user probably shouldn't be giving any command
line options (or very few) anyway, but should be twiddling bits in the
options file to make them persistent.

    >> Deprecated form: "-d ~/hammie.db" found.
    >> Use "-o Storage:persistent_storage_file:~/hammie.db" instead.

    Kenny> I don't know if it's good to go that far.  The new syntax is
    Kenny> rather cumbersome, especially if I'm typing the command manually.

I can buy that, though if you're using a modern shell, command recall can
mitigate most of that.  (I don't think DOS shells or vanilla /bin/sh qualify
as "modern shells".  I'm talking tcsh, bash, ksh, etc.)

    Kenny> Also, some command line flags can set several related option
    Kenny> values to the correct combination (e.g. set both the database
    Kenny> filename and type with one flag), and the new syntax would
    Kenny> require knowing the correct combination and providing all the
    Kenny> correct values.

I think that's more confusing than it ought to be.  Having -d and -D
simultaneously set two options seems 

    >> This could be extended further.  Should the user give an incomplete
    >> -o flag such as "-o Storage" or "-o Storage:spam_cache", help about
    >> that section or variable could be emitted:

    Kenny> What about options that have no effect on the application being
    Kenny> run?  

I hadn't considered that.  

    Kenny> Would it be possible to detect them and show help in that case
    Kenny> also?

I suppose so, but the application would then have to register all the
options it's interested in.  How would the application author know what all
the storage options were without diving into storage.py and friends?

    Kenny> How would we present a list of useful options to the end user
    Kenny> without overwhelming them with rarely changed settings and gory
    Kenny> internal details?

Experiment, I suppose.

It appears the majority of users will use the Outlook plugin for which this
doesn't apply.  I suspect I'm appealing more to the propeller heads among
us.

Skip