Hi Glenn, Philip et. al,<br><br><div class="gmail_quote">2009/3/25 Glenn Waldron <span dir="ltr"><<a href="mailto:gwaldron@gmail.com">gwaldron@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>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.</div>

</div></blockquote></div><div><br>That would be the idea, yes. In particular I was looking at pacparser (<a href="http://code.google.com/p/pacparser" target="_blank">http://code2009/3/24 Philip Lowman <span dir="ltr"><</span></a><a href="mailto:philip@yhbt.com" target="_blank">philip@yhbt.com</a>><br>
</div></div></blockquote></div><br>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.<br><br>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?<br>
<br>Robert.<br>