>> 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 [email protected] >> >> 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
