Re: libproxy as external dependency
- From: Nathaniel McCallum <nathaniel natemccallum com>
- To: Ali Sabil <ali sabil gmail com>
- Cc: Ross Burton <ross burtonini com>, desktop-devel-list gnome org, Xavier Bestel <xavier bestel free fr>
- Subject: Re: libproxy as external dependency
- Date: Sat, 25 Oct 2008 13:38:24 -0400
Ali Sabil wrote:
This is basically true. There are three steps to initiating a
connection to a host through a proxy.
2008/10/24 Ross Burton <ross burtonini com <mailto:ross burtonini com>>
On Fri, 2008-10-24 at 11:09 +0100, Rui Tiago Cação Matos wrote:
> In this specific library case, since the API is so simple and you
> don't know you need it until you somehow check your app's settings
> it's a no-brainer really.
You could lazy-load the library when you need to access a URL, but the
point is that your app shouldn't have to know how to handle proxies or
check settings: it just asks the library to handle them.
From what I understood, libproxy only allows your to know which proxy
to connect to for reaching a specific resource, not how to handle the
proxy, as you are supposed to handle them yourself.
1. Load proxy configuration
2. Evaluate proxy configuration (ex. WPAD, PAC and ignore lists)
3. Establish connection through the proxy
libproxy covers #1 and #2. #3 is protocol specific. Since libproxy
can't implement every protocol out there, it is up to your protocol
layer to do step #3. This is the job of, say, libsoup. So, if your
application uses libsoup, you shouldn't need to know anything about proxies.
However, some applications have the protocol layer built-in. An example
of this might be xchat. libproxy will do #1 and #2, but xchat will need
to program #3.
Ideally, each protocol should be split into a library which would
] [Thread Prev