Re: Proxy support over AF_UNIX

[Ben Boeckel <mathstuf gmail com>]

After doing some hacking, things are looking clearer. Thanks for the
pointers. However, it looks like there's a roadblock.

It seems as though, because of all the abstraction and such, I have no
sane way of pumbing through both a "fake" proxy URI for GSocketClient to
do it's speculative connection with *and* the actual path for the socket
path I'd like to connect to. There's only one entry point for the string
and I don't see a way to create a specially-crafted GProxyAddress to
pass around in its place (which I'm hesitant to use in case it starts
breaking assumptions that might arise in future versions such as "given
uri, set the other properties" or "if uri is set, use it; ignore other
parameters", etc.).

This has led me to this thought though:

On Tue, Feb 26, 2013 at 22:30:37 +0100, Dan Winship wrote:
> So you have to allow GSocketClient to make a TCP connection to
> *somewhere*...

Or, instead of trying to be jump the gun, GSocketClient should just let
the GProxy implementations do the actual connections. The current
g_proxy_connect is actually more like g_proxy_negotiate. Instead of the
current special-casing logic, GSocketClient could always use a proxy.

A new class heirarchy could look something like:

    GProxy
    |-- GTcpProxy
    |   |-- GHttpProxy (might also handle the "no proxy" case?)
    |   |-- GHttpsProxy (might also handle the "no proxy" case?)
    |   |-- GSocks4aProxy
    |   \-- GSocks5Proxy
    \-- GUnixProxy
        |-- GUnixAbstractSocketProxy
        \-- GUnixSocketProxy

It might be possible to do this without breaking binary compatability if
the old proxy implementations which don't live in GIO could be shimmed
via a GTcpProxy subclass followed by g_proxy_connect call (do any of
these even exist?).

--Ben