bug#16026: Connection specific settings and proxies

[Michael Albinus <michael.albinus@gmx.de>]

Ted Zlatanov <tzz@lifelogs.com> writes:

Hi Ted,

> 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?)

Well, I've stolen the "class" name from directory-local variables. The
concept of connection-local variables is closed to that of directory-local.

No problem to rename it, if it helps. And sometimes I'm even not sure
whether we need the class/profile concept; it might be even sufficient
to bind variables to connections directly, like variables can be bound
directly to buffers.

> 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

Well, currently a class is bound to a connection via a regexp, which is
used for checking the result of `file-remote-p'. This is good for Tramp,
but it is less good for url-* functionality unless `url-handler-mode' is
enabled, and it does not work for other applications like imap-based
connections.

Your proposal looks OK to me. U, Y and Z shall be regexps, X a symbol
(or also a regexp?). All of them shall be optional.

> Ted

Best regards, Michael.