<div dir="ltr">On Thu, Jun 6, 2013 at 6:55 AM, David Woodhouse <span dir="ltr"><<a href="mailto:dwmw2@infradead.org" target="_blank">dwmw2@infradead.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Wed, 2013-06-05 at 12:08 +0800, Christopher Meng wrote:<br>
> libproxy taken.<br>
<br>
I'm also very interested in libproxy. Would you mind if I comaintain it?<br>
<br>
I've been meaning to deal with proxy configuration in Fedora for a<br>
while. For those who use an environment where *all* external access has<br>
to be through proxies, Fedora is just horrid to use. The out-of-the-box<br>
behaviour for *every* HTTP client application is fairly much broken, and<br>
you have to manually configure *each* of them to make them work.<br>
Repeatedly, each time you enter or leave that horrid proxy-requiring<br>
environment.<br>
<br>
Libproxy, or something like it, is the solution to this. What we really<br>
need to happen is:<br>
<br>
- NetworkManager picks up proxy information (from DHCP, VPN server,<br>
autoproxy or explicit configuration for the connection in use)<br>
<br>
- *EVERY* application just asks "what proxy should I use for this<br>
URL" by default, unless it's explicitly configured otherwise.<br>
<br>
And thus, in one fell swoop, the problem is solved.<br>
<br>
In fact the original libproxy is fairly horrid. It's an overcomplex C++<br>
monstrosity which runs the full JS interpreter in the context of *every*<br>
application which ever needs to check if it needs to use a proxy.<br></blockquote><div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">I agree. And I wrote it. :(</div><div style="font-family:arial,sans-serif;font-size:13px">
<br>Unfortunately, the JS interpreter can't disappear. WPAD is *very* widely deployed and requires it. We can mitigate it by stuffing it in a session daemon.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
There's a much saner, ABI-compatible, replacement in PacRunner, which<br>
has a dćmon which sits on DBus and answers questions. Its<br>
"libproxy.so.1" replacement is just a trivial DBus client, and that's a<br>
much better way of doing things. I'll be putting in a review request for<br>
pacrunner shortly.<br></blockquote><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">This approach is much better for Linux, but it doesn't work on other platforms. And libproxy is widely used precisely because it is multi-platform. I'd like to retain this (even if we retain none of the original code). In general however, I don't want us to have multiple choices between incomplete implementations. Let's either fix libproxy or make something like pacrunner multiplatform.</span><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In the meantime, though, there's nothing to stop us continuing the<br>
process of fixing all applications and http libraries to use libproxy.so<br>
by default. We've done some, and there's more to be done. I'm half<br>
tempted to submit it as a Feature for F20.<br>
<br>
Is anyone else interested in getting this fixed?<br></blockquote><div><br></div><div style>Yes. </div></div></div></div>