Re: bug#16026: Connection specific settings and proxies

[Ted Zlatanov]

On Fri, 03 Feb 2017 16:37:52 +0100 Michael Albinus <address@hidden> wrote: 

MA> Ted Zlatanov <address@hidden> writes:
MA> 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?)

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

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

I think from the user's side, it's necessary. We have to associate the
data with a profile, which is then exposed as a configurable entity.

Let's call them "connection profiles" to be very clear, since just
"profile" can be ambiguous as well.

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

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

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

Wonderful. I propose that the application should be a defgroup symbol,
and every connection profile should be required to have a defgroup.

That would give us an implicit connection profile hierarchy and a place
to hook connection profile customizations at the UI level.

So defining connection profiles would be something like this:

(add-connection-profiles :user U :defgroup X :protocol Y :machine Z
                         :profile 'UXYZ :vars '(...))

(add-connection-profiles :profile 'general :vars '(...))

And then the application Gnus would do (note it's required that the
defgroup 'gnus exists):

(connection-profile-get-local-variables :defgroup 'gnus ...other criteria...)

>From the user's side, they would say

M-x customize-connection-profile UXYZ ; change criteria or settings
M-x customize-connection-profile general ; change criteria or settings
M-x create-connection-profile atwork ; specify desired settings
M-x connection-profiles ; some kind of table/list UI

Let me know what you think.

Thanks
Ted