Re: Mailutils configuration, some work needed

[Sergey Poznyakoff]

> 
> Ok, Sergey, while we're both awake,

:^))

> I think we can
> make the configuration work a little better.
[...]
> --maildir parsing is something that has to be explicitly coded
> for by users of the mailbox API who want to open the spool.
> 
> I would like mailbox_open_default() to behave like this:
> 
>   "sroberts" -> if it exist in the cwd, detect 
>      the spool for sroberts, using the --homedir specification.
> 
>   NULL -> $(USER) -> spool for $(USER)
> 
>   ! -> NULL -> see above
> 
>   ~/INBOX  -> $(HOME)/INBOX
> 
>   +file -> expand to ~/Mail/file -> $(HOME)/Mail/file
> 
> Where $(USER) is the env variable, or pulled out of /etc/passwd,
> and likewise for $(HOME).

Agreed. Actually I've been thinking of it for quite a while now.
I was figuring out such a way to do it that won't break anything
that is already built and working...

> There's a bunch of ways to do this. 
[...]
>   char* mailbox_maildir = NULL; /* NULL means uses MU_PATH_MAILDIR
> 
> You can set it:
> 
>   mailbox_set_maildir(const char* maildir);
> 
>   mailbox_open_default() will use mailbox_maildir if it needs to 

OK.

> We're close to this with your common opts, but:
> 
> - the global variables set aren't known to the mailbox code

Yes, that is a major drawback.

>   How about if mu_common_argp_parser() calls a:
>     mailbox_set_maildir(), so the arg is used by mailbox_open_default()
>     mu_syslog_set_facility() so the arg is used by mu_syslog_error_printer()

Something like that:

int
mu_common_argp_parse(
 const struct argp *argp,  /* Structure describing what and how to parse */
 int argc, char *argv[],   /* Arguments from main(): before processing
                            * these are complemented with the contents
                            * of system-wide and user-specific
                            * configuration files (e.g.
                            * /etc/mailutils.rc /home/gray/.mailutils */
 unsigned flags,           /* arpg_parse flags */
 int *arg_index,           /* Out: index of the last processed
                            * option */
 void *input               /* In/Out: Any application-specific data */
);


mu_common_argp_parse() is supposed to call mu_argcv_get() before
passing arg[cv] to argp_ functions for further processing.

[...]
>   mu_argcv_get() either takes an extra arg, the name of a rc file, and
>   makes an argv containing:
>     mailutils (maildir and syslog facility) from /etc/mailutils/rc
>     everything from ~/.<argv[0]>rc OR the extra arg
>     everything from the command line
> 
>   Would that be OK with you?

Quite OK. I even don't think we would need any extra argument, since
naming the configuration file for each utility after its name is quite
straightforward and follows the usual unix paradigm.

>   /etc/mailutils.rc is currently 2 level, global and command-specific.
>   But the "global" is too global. Does mail.local use the SQL and

Sure, it does! These are used by mu_getpw stuff.

>   PAM stuff?

No, not currently, but it may come handy sometime. These are made
common and not daemon because a site may use SQL users database
on its mailserver, and these options will be needed by imap4d, pop3d
and mail.local, so instead of repeating them in three different places
it seems more convenient to specify them just once, in `mailutils'
stanza. On the other hand, this way the utilities that don't need
these options, will not complain about them.

>   char* capa[] = { "authstuff", "maildir", "syslog", NULL }
> 
>   mu_argcv_get(argc, argv, "~/.utilrc", &av, &ac, capa);
[...]
>   If we pass in a capa array, we can pull the exact pieces out we
>   need, so you can have a ~/.mailutils.rc, and say I want the
>   sieve options and the maildir options.

Isn't it already specified by struct argp? For the common mailutils
options, the options which are not used by a particular program are
silently ignored. The effect is the same as with capa[] array, except
that obviously incorrect options, like

mail.local --daemon=10

will cause the utility to complain, whereas using capa[] would sieve
them off silently.

The idea behind creating utility-specific and global option sets was to
provide a convenient way to abbreviate things, while still enforcing
a rigorous invocation syntax checking.

> Do you have any comments on this approach, or maybe some other
> suggestions? I can start working on this this weekend if we
> have something that works to unify the server-side and client-side
> utility configurations. I think the mu_argp stuff brings us
> pretty close already.

OK, except my note on capa[] stuff, I quite agree with your
propositions. I believe I'll be able to finish
mailbox_set_maildir/mailbox_open_default part tomorrow, so 
you can start hacking on mu_argp.

Regards,
Sergey