unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: Ted Zlatanov <tzz@lifelogs.com>,
	16026@debbugs.gnu.org, Stefan Monnier <monnier@IRO.UMontreal.CA>,
	Emacs developers <emacs-devel@gnu.org>
Subject: bug#16026: Connection specific settings and proxies
Date: Thu, 02 Feb 2017 04:43:10 +0100	[thread overview]
Message-ID: <m3efzhmf5d.fsf_-_@stories> (raw)
In-Reply-To: <87h94fqjq7.fsf@gmx.de> (Michael Albinus's message of "Tue, 31 Jan 2017 17:26:08 +0100")

Michael Albinus <michael.albinus@gmx.de> writes:

>> It's easy to create an ad-hoc system just for network timeout
>> parameters, like I did with many GnuTLS parameters early on, but the
>> systematic approach Michael gave us is much better. The only reason I
>> haven't implemented it is lack of time.
>
> If I could help, just ping me. Not that I have too much free time, but
> I'm interested in this.

I was just pondering something that's perhaps related: HTTP proxying in
the with-url branch.

url.el uses an alist on the form ((("http" . "foo.bar:port")
"proxy:port")) or something to determine what connections should be
proxied.  It doesn't support HTTPS proxies (i.e., "CONNECT"), so it's
rather underspecified, if I read the code correctly.

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

If the latter, you could see having a call like

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

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

Now, this all kinda ties in with what Ted was talking about: A
per-connection setting thing.  So you could envision doing just the same
with, say, IMAP, if you need to have that be proxied or something, and
then it turns out that the right layer for this stuff is probably in
`open-network-stream': Almost all networking already goes through that
function, so by implementing it there, all clients get automatic proxy
support.

The same mechanism for determining things like lifecycle settings (i.e.,
network timeout parameters) could somehow be squeezed in here.

But I've read the doc for connection-local-set-class-variables, and I
don't quite see how to match up these needs with that mechanism...

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

So many options...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2017-02-02  3:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7856.1385996719.10748.bug-gnu-emacs@gnu.org>
     [not found] ` <mailman.7856.1385996719.10748.bug-gnu-emacs-mXXj517/zsQ@public.gmane.org>
2013-12-02 15:19   ` bug#16026: Gnus shouldn't use old connections Sebastien Vauban
2013-12-02 16:12     ` Stefan Monnier
2013-12-04 16:04       ` Ted Zlatanov
2017-01-25 16:55         ` Lars Ingebrigtsen
2017-01-25 18:26           ` Stefan Monnier
2017-01-30 20:12             ` Ted Zlatanov
2017-01-30 22:38               ` Stefan Monnier
2017-01-31 14:37                 ` Ted Zlatanov
2017-01-31 16:26                   ` Michael Albinus
2017-02-02  3:43                     ` Lars Ingebrigtsen [this message]
2017-02-02 14:46                       ` bug#16026: Connection specific settings and proxies Ted Zlatanov
2017-02-02 23:58                       ` Daniel McClanahan
     [not found]                       ` <87o9ykr6os.fsf@flea>
2017-02-03 15:37                         ` Michael Albinus
2017-02-06 15:22                           ` Ted Zlatanov
     [not found]                           ` <87k293ny36.fsf@flea>
2017-02-12 17:42                             ` Michael Albinus
     [not found]                             ` <87d1enz4p2.fsf@gmx.de>
2017-02-20 16:01                               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3efzhmf5d.fsf_-_@stories \
    --to=larsi@gnus.org \
    --cc=16026@debbugs.gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).