Re: [nmh-workers] success using the OAUTH2 with gmail.

[Ken Hornstein]

>> 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 address@hidden
>>
>> 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