Let's say in a hypothetical future we support IMAP. That means that
nearly every command would take a whole pile of arguments like
-initialtls, -host, -port, -sasl, and more. Obviously changing your
profile for every nmh command would be awful. So there should be some
way of handling that. What I had thought maybe was tying profile
entries to mailboxes, so if you did "scan my-imap-server:foo" it could
possibly look in your profile and find:
my-imap-server: -host my.server.com -port imap -tls -sasl
-saslmech GSSAPI -user me
That seems very specific and introduces a new colon operator that
restricts what's available for other features later.
Well, it was just a strawman .... like I said, I'm not really sure about
it yet. It seems a bit clumsy that you have to add that folder-specific
config file to bind an IMAP folder, but maybe extending the folder(1)
command would work? More thought is needed.
How about allowing an mh-profile(5) in a folder's directory with its
content having higher priority than the ancestor folders' .mh_profile
and the general ~/.mh_profile. This could be used for more general
things, e.g. the template used for replies to emails in that folder, or
the preferred format for scanning it.
In that vein, when playing around with DavMail I found that it cached
a lot of message headers with IMAP but not the message bodies, so a
theoretical scan template which fetched the first part of the body
of the message has lousy performance, so that's a case where you would
want a folder-specific scan template. Something else to think about.
You get the idea. But thinking about this more makes me think that we
should extend this a bit so it's not tied to folders, but a generic
connection profile defaults and we could provide ones that work with
Gmail. I don't have it all jelled in my head how this would look and
you'd need to do something to ADD to an existing connection profile so
you could supply your own username, for example. But it seems like it
should be doable. But I guess my idea is that you should be able to
do something like
inc -conn gmail -user myuser@gmail.com
and the right stuff should happen. Make sense?
If `foo: -bar xyzzy...' is in an .mh_profile then often, depending on
the value's complexity, it can be interpolated with «`mhparam foo`» in
the shell. What if a similar capability existed on the value side of an
.mh_profile's `key: value'. Except it could cope with the interpolated
value having quotes.
This would allow collections of options to be defined and then
referenced with a shorthand. Either back quotes copied from sh(1), or
`-use foo' so it can work easily at the shell too.
Well ... I see where you are going. But ...
It occurs to me that one problem with our configuration, especially for
newer users, is that it's all spread out between different tools. For
example, your SMTP servers settings are in send(1) (and if you want
to be complete, probably whom(1) as well), POP server settings belong
in inc(1) and msgchk(1), and with a theoretical IMAP server it would
be a lot of tools. This is confusing.
When users are given information about the settings for an email provider,
they are usually given them all at once. "Here's the SMTP server, here's
the POP server, here's the IMAP server", etc etc. So if we had some
facility where we could say "Here's where you put the block of network
settings for GMail", for example, and then we could have people just
refer to the "gmail" settings, that would be a huge win. Making those
things easily be extractable via mhparam would also be a huge win.
Again, I'm not sure what all of this would look like right now.
This is just idle musings.
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers