[meego-packaging] A new libproxy 0.4.5
Li, Yan I
yan.i.li at intel.com
Wed Aug 25 01:40:02 PDT 2010
On Wed, Aug 25, 2010 at 04:11:12PM +0800, David Woodhouse wrote:
> On Wed, 2010-08-25 at 08:55 +0100, Li, Yan I wrote:
> > > Hm. But that means we're loading the PAC file and running the JS
> > > interpreter again in every client application.
> > The PAC script must be run on every distinct HTTP request, this is by
> > design of PAC.
> Yes, you have to run the PAC script every time. But you don't have to:
> - load a fresh copy of the WebKit library into a process which didn't
> previously have it
> - work out where the PAC file comes from (by asking ConnMan)
> - download the PAC file
> - parse/interpret the PAC file for the first time
I've opened a bug upstream:
That being said, the memory occupied by the webkit library is shared
among processes, I don't think this is going to be a big problem per
se. A little OT: the currently WebKit disaster in MeeGo now is due to
there are 3 unshared copies of WebKit loaded into memory: one is the
WebKit-gtk library, one is within Chrome, and one is from
QtWebKit. This can't be soothed if we continue to use Chrome instead of
Chromium, and the disparate between WebKit-gtk and QtWebKit is not
easy to cure.
I quickly checked the code and saw libproxy caches the PAC file (I
maybe wrong). I think this is OK. If it didn't work we can fix it.
> Pushing WebKit into *every* client seems like the wrong approach.
MeeGo Team, Opensource Technology Center, SSG, Intel
Office tel.: +86-10-82171695 (inet: 8-758-1695)
OpenPGP key: 5C6C31EF
IRC: yanli on network irc.freenode.net
More information about the MeeGo-packaging