bug#16026: Connection specific settings and proxies

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 02 Feb 2017 04:43:10 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> I'm also not sure what level to put the proxies on: Should they be
LI> passed in from the application (i.e., eww, Gnus, etc) or should it be a
LI> global Emacs setting?

LI> If the latter, you could see having a call like

LI> (set-proxy :match-domain ".*\\.foo\\.bar\\'"
LI>            :target-port 443
LI>            :proxy-server "localhost"
LI>            :proxy-port 80
LI>            :method 'connect)

LI> to set up the proxy.  (Well, really, you'd have a mode that would allow
LI> you to tweak the global proxy setup.)

The way Michael set it up, you have connection profiles ("classes") that
can be associated with any variables. (For passers-by, see
`connection-local-set-class-variables', `connection-local-set-classes',
and `with-connection-local-classes'). Profiles can be overlaid to
augment each other.

(Michael: maybe it's not too late to change "class" to "profile"
because the former is so overloaded in our field?)

LI> And, like I said, I don't know whether it's the right design choice to
LI> have these settings be global, or whether they should be passed in
LI> explicitly from each application.  Would users want to use one set of
LI> proxies while reading HTML news from Gnus and another when reading from
LI> eww?  Perhaps?  Perhaps not?

I see. I think the classes should be associated with applications and
protocols and login names, not just connections. Michael, what do you
think? That would require changing the identification parameter to
`connection-local-get-classes' to be an alist or a plist like
:user U :application X :protocol Y :machine Z

I can imagine more criteria in the future, so the identification should
be flexible. This has a pretty big semantic overlap with how auth-source
selects credentials and NSM applies security polity, so I think it makes
sense to absorb those things into the same hierarchy. So IMO this is a
chance to consolidate a lot of disparate code and improve the user
experience.

Then you could have:

"class C1(contains the proxy P1) for IMAP to machines A B C"
"class C2(contains the proxy P2) for everything"
"class C3(contains the proxy P3) for machines B C D"

So IMAP to machine B would get C1/P1, but HTTP to machine B would get
C3/P3 (all the matching classes should be applied in specificity order
so the most specific one wins).

Not all parameters apply everywhere, so we're looking to extract the
truly global ones first: network timeout, proxies, NSM policy, GnuTLS
parameters, auth-source entries.

Ted