2009/3/25 Robert Osfield <[email protected]> > Hi Glenn, Philip et. al, > > 2009/3/25 Glenn Waldron <[email protected]> > >> 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/pacparser>[email protected]> >> > > 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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
