WebKit/GTK+ integration tracking bug

[markcox]

WebKit/GTK+ integration tracking bug

[GoogleCodeExporter]

#1) Not currently, however, I'm not opposed to it.  What would be your preferred
method of implementation?

#2) I will create some performace documentation.  In short, we cache as often 
as the
spec will allow (hence, why the networkmanager plugin is important).  This 
cache is
kept in the proxy factory object, so keeping it around as long as possible is a
GoodThingTM.  get_proxy() always blocks and can be run in its own thread.  
Generally
speaking, the slowest possible execution is WPAD on the first get_proxy() call. 
After that, so long as the cache is valid, get_proxy() will be a single 
javascript
invocation.  In the case of non-WPAD/PAC, there is minimal overhead on top of 
the
underlying mechanism (ie. envvar, gconf, etc).

In summary, the idea is this: keep the pxProxyFactory instance around as long as
possible.  If you do this, any performance issue is considered a bug.  
Performance is
important to us.

#3) My suggestion to the libcurl guys was to support libproxy directly in curl. 
 They
seemed to balk at that idea.  I will take some time this week to generate some 
docs
on how to integrate libproxy with libcurl.

Original comment by [email protected] on 6 Oct 2008 at 6:21

[GoogleCodeExporter]

Original comment by [email protected] on 6 Oct 2008 at 7:02

[GoogleCodeExporter]

Targeting for 0.3

Original comment by [email protected] on 6 Oct 2008 at 7:46

• Added labels: Type-Enhancement, Priority-High, Milestone-Release0.3
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

There is a first patch ready that reads from the environment which plugins are
preferred. In case loading them should not be possible, the others serving an 
equal
function will be tried.

Patch to be reviewed

Original comment by [email protected] on 10 Oct 2008 at 6:25

• Changed state: Started

[GoogleCodeExporter]

patch commited as svn 273; documentation in the wiki is still missing.

in short: the environment variable PX_PLUGIN_ORDER can contain a comma 
separated list
of plugins that will be tried in this order. All the remaining plugins will be 
loaded
afterwards.

Like this you can specify for example webkit in the PX_PLUGIN_ORDER; it will be
loaded first.

Original comment by [email protected] on 16 Oct 2008 at 6:32

[GoogleCodeExporter]

I should point out that PX_PLUGIN_ORDER will be referenced at pxProxyFactory
instantiation time.  So if you want webkit to be used, you'd do this:

setenv("PX_PLUGIN_ORDER", "webkit", 1);
pxProxyFactory *pf = px_proxy_factory_new();
...

Original comment by [email protected] on 18 Oct 2008 at 8:48

[GoogleCodeExporter]

Performance documentation is now in the header file and the HowTo wiki page.  
Still
outstanding is is libcurl sample code.

Original comment by [email protected] on 18 Oct 2008 at 9:37

[GoogleCodeExporter]

There is now a sample libcurl implementation in the samples directory in the 
most
recent trunk.

Original comment by [email protected] on 20 Oct 2008 at 7:27

• Changed state: Fixed

[GoogleCodeExporter]

I'm re-opening this bug to point out that PX_PLUGIN_ORDER will no longer work 
like
this in the current trunk.  I'll make sure to come up with a new way to do this 
for 0.3.

Original comment by [email protected] on 15 Mar 2009 at 3:21

• Changed state: Accepted

[GoogleCodeExporter]

In revision 329 in trunk I've added support for PX_PLUGIN_BLACKLIST.  It is an
environmental variable that takes a comma separated list of plugin names to 
blacklist.

Thus, when webkit would use libproxy, you would specify:
PX_PLUGIN_BLACKLIST=pacrunner_mozjs

Original comment by [email protected] on 19 Mar 2009 at 1:58

• Changed state: Fixed