Re: [osg-users] Proxy auto-config (PAC) support
Hi Glenn, Philip et. al, 2009/3/25 Glenn Waldron gwald...@gmail.com PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser (http://code2009/3/24 Philip Lowman http://code.google.com/p/pacparserphi...@yhbt.com I really don't know anything about this particular topic, neither much about proxies or java script... but a few thoughts about the possible integration side. First up I'd suggest that if possible one should decouple the extra java script based proxy support from the plugin as we don't want a simple plugin with modest dependencies becoming burden with optional dependencies, as it'd mean that the plugin behaves differently in different builds. Might it be possible to decouple the Java script/PAC support completely. Perhaps via another plugin? Perhaps via Registry::ReadFileCallback? Or at the application level? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/25 Robert Osfield robert.osfi...@gmail.com Hi Glenn, Philip et. al, 2009/3/25 Glenn Waldron gwald...@gmail.com PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser (http://code2009/3/24 Philip Lowman http://code.google.com/p/pacparserphi...@yhbt.com I really don't know anything about this particular topic, neither much about proxies or java script... but a few thoughts about the possible integration side. First up I'd suggest that if possible one should decouple the extra java script based proxy support from the plugin as we don't want a simple plugin with modest dependencies becoming burden with optional dependencies, as it'd mean that the plugin behaves differently in different builds. Might it be possible to decouple the Java script/PAC support completely. Perhaps via another plugin? Perhaps via Registry::ReadFileCallback? Or at the application level? That's an idea -- make a .js plugin that loads a javascript file and runs a function. We could pass in params using the plugin options, and use readObject() to return ... not sure what. Then the CURL plugin could detect a PAC file and read it w/ the JS plugin. Anyway I like the idea of a JS plugin but it's not clear what the interface would look like. Glenn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
Hi Glenn, 2009/3/25 Glenn Waldron gwald...@gmail.com That's an idea -- make a .js plugin that loads a javascript file and runs a function. We could pass in params using the plugin options, and use readObject() to return ... not sure what. Then the CURL plugin could detect a PAC file and read it w/ the JS plugin. Anyway I like the idea of a JS plugin but it's not clear what the interface would look like. A PAC plugin that uses something like pacparse would be more straight forward. A full javescript plugin/support is rather more open ended. It would be interesting to have general javascript support, especially for webbrowser integration, but this is whole topic in itself and well beyond the scope of a plugin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/25 Robert Osfield robert.osfi...@gmail.com Hi Glenn, 2009/3/25 Glenn Waldron gwald...@gmail.com That's an idea -- make a .js plugin that loads a javascript file and runs a function. We could pass in params using the plugin options, and use readObject() to return ... not sure what. Then the CURL plugin could detect a PAC file and read it w/ the JS plugin. Anyway I like the idea of a JS plugin but it's not clear what the interface would look like. A PAC plugin that uses something like pacparse would be more straight forward. A full javescript plugin/support is rather more open ended. It would be interesting to have general javascript support, especially for webbrowser integration, but this is whole topic in itself and well beyond the scope of a plugin. Sounds like a plan. I will start working on it once I get approval.. Glenn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/25 Robert Osfield robert.osfi...@gmail.com Hi Glenn, Philip et. al, 2009/3/25 Glenn Waldron gwald...@gmail.com PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser (http://code2009/3/24 Philip Lowman http://code.google.com/p/pacparserphi...@yhbt.com I really don't know anything about this particular topic, neither much about proxies or java script... but a few thoughts about the possible integration side. First up I'd suggest that if possible one should decouple the extra java script based proxy support from the plugin as we don't want a simple plugin with modest dependencies becoming burden with optional dependencies, as it'd mean that the plugin behaves differently in different builds. Might it be possible to decouple the Java script/PAC support completely. Perhaps via another plugin? Perhaps via Registry::ReadFileCallback? Or at the application level? Here are a couple of other options I thought of I'll throw out there 1. Build the curl plugin twice, once with curl and once with curl + pacparser (or whatever). Make it so the latter plugin is preferred in Registry.cpp if PAC usage is enabled, the plugin is available and it's loadable. This option might simplify some of the passing you'd otherwise have to do between the plugins if multiple plugins are used (I assume environment variables can't be used for this to set http_proxy/etc. due to multiple download threads). 2. use dlopen+dlsym in the existing curl plugin since pacparser is fairly lightweight and only has 4-5 functions. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Proxy auto-config (PAC) support
I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/24 Glenn Waldron gwald...@gmail.com I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. Ultimately though it's far easier just to have a human being read the PAC file and say thou shalt export http_proxy=http://foo.internal.com:8080; prior to running the OSG. For servers that don't need the proxy server you can either configure the proxy server to tell the client to access the server directly or you can use the no_proxy environment variable which I believe libcurl respects. If you have a situation where you have to switch between two different proxy servers depending on the URL you are accessing clearly something is wrong with your IT people at work... :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/24 Philip Lowman phi...@yhbt.com 2009/3/24 Glenn Waldron gwald...@gmail.com I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser ( http://code.google.com/p/pacparser) which I believe uses spidermonkey for JS. Ultimately though it's far easier just to have a human being read the PAC file and say thou shalt export http_proxy=http://foo.internal.com:8080; prior to running the OSG. Don't know about all that ... never underestimate an IT department's ability to deploy an overly-complex proxy and firewall setup :) But seriously, PAC is a fact of life in some big corporate environments and does justify the need for an app that just works with it out of the box. For servers that don't need the proxy server you can either configure the proxy server to tell the client to access the server directly or you can use the no_proxy environment variable which I believe libcurl respects. If you have a situation where you have to switch between two different proxy servers depending on the URL you are accessing clearly something is wrong with your IT people at work... :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/24 Glenn Waldron gwald...@gmail.com 2009/3/24 Philip Lowman phi...@yhbt.com 2009/3/24 Glenn Waldron gwald...@gmail.com I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser ( http://code.google.com/p/pacparser) which I believe uses spidermonkey for JS. It would be nice in that the OSG could at least in theory work with proxy servers without being configured at all. For servers that don't need the proxy server you can either configure the proxy server to tell the client to access the server directly or you can use the no_proxy environment variable which I believe libcurl respects. If you have a situation where you have to switch between two different proxy servers depending on the URL you are accessing clearly something is wrong with your IT people at work... :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
