Re: libproxy as external dependency
On Thu, Nov 06, 2008 at 03:01:01PM +0100, Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. The only argument I see against libproxy is yet another library while we're trying to reduce the number of libraries and people seemed to agree that this is actually not a real issue. So I guess we can accept it, unless someone else raises another issue? FYI, a member of the Debian security team raised concerns: WPAD is a broken protocol with security issues inherent to the DNS devolution mechanism (which is also performed by libproxy). Please don't add implementations to the Debian archive. http://lists.debian.org/debian-devel/2008/12/msg00737.html Forwarding here without further comments as I have no idea about the security implications. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Michael Banck wrote: FYI, a member of the Debian security team raised concerns: WPAD is a broken protocol with security issues inherent to the DNS devolution mechanism (which is also performed by libproxy). Please don't add implementations to the Debian archive. http://lists.debian.org/debian-devel/2008/12/msg00737.html Forwarding here without further comments as I have no idea about the security implications. As noted in the followups: - The fact that it's broken doesn't change the fact that lots of sites use it - It's already implemented by other programs in the distro anyway (notably Firefox) - Its use in libproxy can be disabled system-wide by the administrator I think in current libproxy WPAD is enabled by default though. We should make sure that's changed. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, Dec 18, 2008 at 11:25 AM, Dan Winship d...@gnome.org wrote: Michael Banck wrote: FYI, a member of the Debian security team raised concerns: WPAD is a broken protocol with security issues inherent to the DNS devolution mechanism (which is also performed by libproxy). Please don't add implementations to the Debian archive. http://lists.debian.org/debian-devel/2008/12/msg00737.html Forwarding here without further comments as I have no idea about the security implications. As noted in the followups: - The fact that it's broken doesn't change the fact that lots of sites use it - It's already implemented by other programs in the distro anyway (notably Firefox) - Its use in libproxy can be disabled system-wide by the administrator I think in current libproxy WPAD is enabled by default though. We should make sure that's changed. Regarding libproxy enabling WPAD by default, this is both true and false. Since one of the goals of libproxy is to read configurations from other sources, we will use whatever is the default for the highest priority configuration source. In the case of GNOME, if libproxy is used in GNOME, libproxy will use whatever is the default configuration in gconf. By default gnome-network-properties disables WPAD. However, if no configuration is found (which should hopefully never happen) we do fall back to WPAD. Perhaps this should be changed? Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, 2008-11-06 at 15:01 +0100, Vincent Untz wrote: So I guess we can accept it, unless someone else raises another issue? I think we have to accept it. It's a stable library that solves a real problem written by people who are approachable and know what they are doing. +1 from me. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? libproxy reads the configuration from gconf every time a new connection is established. IMHO, it is a bad practice to tear down a working connection so that you can try to establish a new connection which *might* work (or might fail). Best practice should be to keep all operational connections established and only use the new proxy settings for new connections. Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le jeudi 06 novembre 2008, à 07:59 -0500, Nathaniel McCallum a écrit : Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? libproxy reads the configuration from gconf every time a new connection is established. IMHO, it is a bad practice to tear down a working connection so that you can try to establish a new connection which *might* work (or might fail). Best practice should be to keep all operational connections established and only use the new proxy settings for new connections. What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le jeudi 06 novembre 2008, à 14:32 +0100, Patryk Zawadzki a écrit : On Thu, Nov 6, 2008 at 2:23 PM, Vincent Untz [EMAIL PROTECTED] wrote: What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. But is it likely that the user remembers and manages to switch the proxy *during* the download to save one click? What if while trying to read that PDF you were 90% done downloading another large file (say a DVD iso) that is equally accessible with or without a proxy? Should it be restarted from scratch as there is no guarantee as to data integrity in case of (range GET) resuming with another proxy (a different cached copy comes to mind as a trivial example)? That's why I said it might be up to the application to know what to do :-) But it might be an issue that's not really solvable without user interaction anyway... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. The only argument I see against libproxy is yet another library while we're trying to reduce the number of libraries and people seemed to agree that this is actually not a real issue. So I guess we can accept it, unless someone else raises another issue? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, Nov 6, 2008 at 2:23 PM, Vincent Untz [EMAIL PROTECTED] wrote: What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. But is it likely that the user remembers and manages to switch the proxy *during* the download to save one click? What if while trying to read that PDF you were 90% done downloading another large file (say a DVD iso) that is equally accessible with or without a proxy? Should it be restarted from scratch as there is no guarantee as to data integrity in case of (range GET) resuming with another proxy (a different cached copy comes to mind as a trivial example)? -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, 2008-11-06 at 15:01 +0100, Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. The only argument I see against libproxy is yet another library while we're trying to reduce the number of libraries and people seemed to agree that this is actually not a real issue. Personally, I'm less concerned with how many libraries we happen to depend on to build Gnome than I am with how many interfaces we're presenting to our third-party developers. Ideally, I'd love to see a GLib-level networking library. If that happened to use libproxy, wonderful. But since we don't have the single point of entry right now, exposing libproxy as a potential interface to our developers seems like the reasonable thing to do. That is to say, we should only reduce the number of libraries through unification, not through reduction of features. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, Oct 24, 2008 at 11:40 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Fri, 2008-10-24 at 11:21 +0200, Xavier Bestel wrote: On Thu, 2008-10-23 at 17:35 +, Benjamin Otte wrote: pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users - yet another library, slowing applications startup. only of those that might require a proxied connection, not every single application, which is fairly obvious. s/proxied connection/network connection/ As a user you want all network applications to be proxy aware if you are behind a firewall that requires a proxy. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Sat, Oct 25, 2008 at 7:38 PM, Nathaniel McCallum [EMAIL PROTECTED] wrote: Ali Sabil wrote: 2008/10/24 Ross Burton [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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. This is basically true. There are three steps to initiating a connection to a host through a proxy. 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. Why is #3 protocol-specific? You want to connect to host:port, the proxy configuration says you need to connect to host2:port2, so somebody will need to create the socket, why not do it in libproxy? There's also: 4. Do the actual proxified communication Who is supposed to add the SOCKS 4/5 headers and HTTP proxy stuff? I don't think libsoup (an HTTP library) is supposed to do that, since other protocols will need to do the same (IRC, FTP, etc). It sounds to me that it's the job of libproxy to handle the SOCKS stuff. The current proposal sounds like a libproxy-conf, not libproxy. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Felipe Contreras wrote: There's also: 4. Do the actual proxified communication Who is supposed to add the SOCKS 4/5 headers and HTTP proxy stuff? I don't think libsoup (an HTTP library) is supposed to do that, since other protocols will need to do the same (IRC, FTP, etc). SOCKS will presumably be handled by the gio-based network layer, once that exists. Presumably the case of (ab)use an HTTP proxy to connect to a non-HTTP protocol could be added there as well. If we're going to have an API that creates network connections, it should be a nice, glib-ish API, and libproxy isn't going to provide that, because it's not a glib-based library. It's desktop-agnostic by design. The current proposal sounds like a libproxy-conf, not libproxy. Yes, that's exactly right. The problem libproxy solves is NOT help apps connect to proxies. It's let apps know what proxies they are supposed to connect to, because that seems to be where most of the problems are. (Lots of apps already have support for using a proxy, they just don't have any support for using *the same proxy you already configured somewhere else*.) Making SOCKS work everywhere in GNOME is a bigger problem, which is explicitly outside libproxy's scope. And it's not a proposal, it's working code. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
2008/10/24 Ross Burton [EMAIL PROTECTED] 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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Ali Sabil wrote: 2008/10/24 Ross Burton [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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. This is basically true. There are three steps to initiating a connection to a host through a proxy. 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 utilize libproxy. Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, 2008-10-23 at 17:35 +, Benjamin Otte wrote: pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users - yet another library, slowing applications startup. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 11:21 +0200, Xavier Bestel wrote: On Thu, 2008-10-23 at 17:35 +, Benjamin Otte wrote: pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users - yet another library, slowing applications startup. only of those that might require a proxied connection, not every single application, which is fairly obvious. but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
2008-10-24 klockan 11:40 skrev Emmanuele Bassi: but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. libsoup perhaps? — Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl come on fallen star · i refuse to let you die · so be mine — placebo signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
2008/10/24 Xavier Bestel [EMAIL PROTECTED]: - yet another library, slowing applications startup. Actually, I've been thinking about this problem lately. Why don't people use dlopen() more often? If you use a library in your app which is not intrinsically essential to it (like gtk+ is) why are you linking to it at load time? In general I think GUI apps should be designed to load up as fast as possible, lazily loading and processing as much as possible. 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. Rui ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 12:04 +0200, Wouter Bolsterlee wrote: 2008-10-24 klockan 11:40 skrev Emmanuele Bassi: but humour me: where would you put this functionality? and saying libgnome or gtk+ is not going to cut it. libsoup perhaps? er... http://mail.gnome.org/archives/desktop-devel-list/2008-October/msg00041.html libsoup is going to use this library, but not every project is going to be using libsoup to access proxies. e.g. the dictionary might probably use libproxy to try and connect to the DICT servers, and no libsoup would be involved. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
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. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Fri, 2008-10-24 at 11:09 +0100, Rui Tiago Cação Matos wrote: 2008/10/24 Xavier Bestel [EMAIL PROTECTED]: - yet another library, slowing applications startup. Actually, I've been thinking about this problem lately. Why don't people use dlopen() more often? If you use a library in your app which is not intrinsically essential to it (like gtk+ is) why are you linking to it at load time? In general I think GUI apps should be designed to load up as fast as possible, lazily loading and processing as much as possible. that's already what happens by default: used symbols are only paged in when needed. the default penalty for adding a shared object is 4 kB, and if the library has been written correctly, the amount of dirty RSS memory should be 0. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Dan Winship wrote: Nathaniel McCallum wrote: I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. You need a comma somewhere... Since I know libsoup doesn't currently use it, you must mean either: libproxy is currently used by vlc ... and neon and libsoup and webkit are considering adopting it. OR libproxy is currently used by vlc and neon ... and libsoup and webkit are considering adopting it. Anyway, Nathaniel is proposing this for GNOME primarily so that libsoup can depend on it, and here's the story with that: For various reasons, mostly bad, libsoup has never handled reading the HTTP proxy configuration out of GConf itself, which means that apps using libsoup either have to do it themselves (which sucks), or else they ignore the problem and then don't work for people who need proxies (which also sucks). I've been meaning to fix this for a while, but haven't. Anyway, I'd like to fix it for 2.26, which means either: 1. libsoup takes a mandatory dependency on libproxy or 2. libsoup takes an optional dependency on libproxy, and then also has gconf-specific code to be used in case libproxy isn't present. It can't be libsoup takes an optional dependency on libproxy, and doesn't handle proxies if libproxy isn't present, because then apps can't rely on libsoup doing the right thing for them, so we'd end up with proxy code in *both* libsoup (via libproxy) *and* the apps (via gconf directly), which would be even worse than what we have now. Now I *can* do option 2 (libsoup has codepaths for both libproxy and gconf directly), and that's what I will end up doing if libproxy isn't accepted as an external dependency, but it would be simpler not to have the extra codepath (there are all sorts of icky bits if you want to do this 100% right, like parsing and matching IPv6 network masks in ignore_hosts, etc). Also, if GNOME makes libproxy a required external dependency, that means all distros have to ship it, which then makes it easier for other applications to start depending on it, which brings us one step closer to universal proxy workingness. All of which is to say, +1. One comment? that's all so far? ;) Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users Considering that all cons I can come up with aren't their fault, this has to be a +1 from me. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Tue, 2008-10-21 at 10:30 -0400, Nathaniel McCallum wrote: I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. I'd happily use this in both Sound Juicer and Postr. libproxy has Python, Java, and C# bindings, so I'm very much a +1. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Ross Burton wrote: On Tue, 2008-10-21 at 10:30 -0400, Nathaniel McCallum wrote: I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. I'd happily use this in both Sound Juicer and Postr. libproxy has Python, Java, and C# bindings, so I'm very much a +1. Actually, our Java bindings are yet-to-be-written... :) However, the small API enables bindings to be written easier. Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libproxy as external dependency
Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. libproxy is a library for handling all aspects of proxy configuration and evaluation. Currently, GNOME stores proxy configuration in gconf and expects each application to read settings from there and evaluate them in some manner (i.e. exceptions, WPAD, PAC). This doesn't really scale because things like exceptions, WPAD and PAC are non-trivial, which leads to inconsistent and impartial implementations. For instance, if a user specifies to use auto-configure and does not specify a PAC file, auto-configure does not work for any GNOME application (that I know of). Even if a PAC file is specified, only those applications that provide javascript will actually use it. Applications developers really only have one question when it comes to proxies: Given a network resource, how do I reach it? libproxy answers this question in a simple, consistent, performant and spec-compliant way. There are currently three functions in the (stable) external API. Two of these functions instantantiate/destantiate the a ProxyFactory object. This object provides caching for WPAD/PAC, allowing for increased speed when dealing with these mechanisms. The third function is the get_proxies(char *url) function. Just call the function for each url that you want to fetch and you are guaranteed a spec compliant proxy configuration evaluation. Version 0.3, to be released before GNOME 2.26, will also contain two more functions for getting and setting proxy credentials. Currently we support using mozjs or webkit (javascriptcore), detectable at runtime. We also can determine proxy information on a per-session basis. In other words, if you run a GNOME app in KDE (and it uses libproxy) it will respect KDE's proxy settings (and vice versa). libproxy has no external dependencies in its core. Support for GNOME, KDE, NetworkManager, WebKit, Firefox/mozjs, etc are implemented via plugins. For more detailed information, please see the website listed above. I am also glad to answer any questions you might have. Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Dan Winship wrote: Nathaniel McCallum wrote: I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. You need a comma somewhere... Since I know libsoup doesn't currently use it, you must mean either: libproxy is currently used by vlc ... and neon and libsoup and webkit are considering adopting it. OR libproxy is currently used by vlc and neon ... and libsoup and webkit are considering adopting it. Sorry, that is less than clear! It should read: 1. vlc and neon currently use libproxy 2. libsoup and webkit are considering adopting it. Sorry for the confusion. :) Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
