Re: Mailutils configuration, some work needed

[Sam Roberts]

Quoting Sergey Poznyakoff <address@hidden>, who wrote:
> > --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...

Anything we break we can fix :-)

> > 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 */
> );

I like this interface a lot.

> 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.

Great.

> 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'

Absolutely.

> 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.

I don't think programs should accept ANY arguments that they can't use, and
my capa[] suggestion was meant to address that, not to allow --daemon
to be silently ignored by mail.local, I agree that would be lame!

I didn't explain it very well, I'll elaborate.

If "frm" supports common, and you do frm -?, you will see that
the frm command "supports" about 10 options that it won't actually
use. I would like that not to happen. Sure, it will ignore them, but
why should it silently accept arguments that aren't meaningful for it?

It seems to me that the only "common" argument to all the utilities
is --licence, everything else is potentially meaningless.

For example, I have a utility, "mailer" that has a /bin/sendmail compatible
interface (really, I'll check it in when its complete) which I can use with
mutt to relay  mail to an smtp server. It doesn't need --maildir (never
touches the spool), but it does need --smtp-port, --smtp-host,
--log-facility, and --licence.  I don't think it should accept --maildir as
an option, it makes it seem like it actually cares where your spool is.

"frm" on the other hand, doesn't do any logging, should use
the users spool by default, but doesn't use pam.

> 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.

I agree with the goal, I'd like to not silently ignore unsupported options.
To avoid this, I think we need a capa[] argument, or equivalent mechanism.

In my mailer I might want:

struct argp_child argp_child[] =
{
  { 0, 0, "Common options", 1},
  { &mu_licence_argp },
  { &mu_syslog_argp },
};

frm would have:

struct argp_child argp_child[] =
{
  { 0, 0, "Common options", 1},
  { &mu_licence_argp },
  { &mu_maildir_argp },
};

imap4d would have:

struct argp_child argp_child[] =
{
  { 0, 0, "Daemon options", 2},
  { &mu_daemon_argp },
  { 0, 0, "Common options", 1},
  { &mu_licence_argp },
  { &mu_maildir_argp },
  { &mu_sql_argp },
  { &mu_pam_argp },
};

  (The syntax may be wrong, but you can see where I'm going.)

Now every utility will allow itself to be called with only the arguments
it actually uses. But, if the /etc/mailutils.rc looks like:

mailutils --log-facility=local3

when frm calls mu_common_argp_parse(), --log-facility will appear
as an argument, and it will choke.

So, now that I've broken things by splitting up mu_common_argp to satisfy
my desire to not accept options I don't use, I need to split up
the catgories /etc/mailutils.rc supports (which now are only two -
"global" and "program specific"). If your /etc/mailutils.rc looked like:

# general stuff
spool --maildir=~/mbox
syslog --log-facility=local0
sql   --sql-blah=blah
pam  --whaterver

# program specific
mailer --smtp-host=smtp.example.com
imap4d --daemon --log-facility=mail  # override the default
imap4d --port=66 --other-namespace=/other
mail.local --quota=xxx

Now sql stuff won't be showing up on frm's command line. But how does
mu_common_argp_parse() tell which entries to collect from the file when
building the argvec for a progam? It used to be easy: all the entries in the
"mailutils" line, plus the entries from the line for argv[0], our utility.
Now frm has to say which children it has stuck into its list of children.
Unless mu_common_argp_parse() has a way of looking at the children, and
deducing the options that the child accepts (can you think of a nice way?)
then we need to tell it, thus the capa[] vector.

I don't think its to much work to make frm not accept --log-facility and
mailer not support --maildir.

> > 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.

What do you think of the rational for a capa[]-like mechanism now?

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)