[meego-packaging] A new libproxy 0.4.5

[Li, Yan I]

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:
http://code.google.com/p/libproxy/issues/detail?id=137

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.

-- 
Best regards,
Li, Yan

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