This poses a problem for implementing the use of an automatic, unalterable proxy in Transmission. Safari uses the OS's default proxy settings, primarily those for HTTP and HTTPS data exchanges. The problem with this solution relates to the specialization of proxies. The proposed solution is to use the OS's default proxy settings to garner automatically determined proxy settings for Transmission. Hopefully, what is needed is not too far from that. Sadly it appears that more than half of the "solution" has already been completed. It is bad that the feature was removed and I believe that the proposed remedy actually makes the situation a bit worse.
Oh man I don't know what to say, the situation looks very sad from here. Transmission-daemon: document libcurl's http_proxy environment variable. In Safari, there's a "Proxy" button that opens the OS X Proxy Settings. Transmission-mac: should use OS X's preferences as Safari does. Transmission-gtk: should use gnome-control-center's "Network Proxy Preferences" app. It would restore tracker proxy support, but without reinventing the wheel - the support would come from the system rather than from Transmission. This sounds like a pretty good idea to me, which kills two birds with one stone. Some insightful users suggested that instead of using its own proxy settings, Transmission could "piggyback" on the system's proxy settings. Many users located in Europe and Asia cited privacy concerns.Īnother related issue dovetails this one - GNOME and OS X both have systemwide proxy support. To my surprise, few (if any?) people cared about peer proxy support, but tracker proxy support is a Big Deal to some people.
The conclusion was to remove the feature to see if anyone noticed, as a way to measuring how important the feature was to users, and whether peer-based support should be added. In ticket #3688 ("remove proxy support") I described how I thought Transmission's proxy support as half-assed, and didn't think many people used it.
0 kommentar(er)
