[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: FW: [Fwd: Re: [atf-dev] JavaXPCOM ownership]
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/14/09 7:34 AM, Jacek Pospychala wrote:
> what are time frames for changes towards multi-process browsing you
> mention? I see https://wiki.mozilla.org/Content_Processes and
> mozilla.dev.tech.dom- is this the best source to follow your progress?
Yes. We're hoping to get out-of-process plugins by the end of this year.
Out-of-process tabs (or embedded browsers) will take a fair bit longer.
> At ATF we mostly use XULRunner as an engine to execute JavaScript in the
> same way as real browser would, or to learn how would real browser
> render a particular HTML page. So while we tightly depend, It doesn't
> sound like we would require or have any benefit of multi-process
> browsing - we would be single-process client most of the time. So maybe
> eventual changes wouldn't affect us that much?
It's likely that you could continue to run in single-process mode. That
wouldn't get you much isolation from any browser crashes, though!
> What exactly maintenace effort is required in JavaXPCOM release
> engineering? Maybe I could help there even if the JavaXPCOM finally
> finds it's home in the extensions..
> I'll also try to keep eye on JavaXPCOM bugzilla to help in cases where I
> can...
Well, as we remove JavaXPCOM from the XULRunner core, somebody will need to
build the separate JavaXPCOM binary and then presumably make Eclipse update
site packages out of it. I think that we could probably find a way to give
the maintainer stage access to ftp.mozilla.org so that they could stage
these releases without having to go through a painful process We'll need to
move the site out of the xulrunner/contrib directory.
> The main thing that concerns me about NPAPI or JS level integrations is
> debugging. When using jsd, debugging Javascript from javascript doesn't
> sound like the best idea, because eventually our debugging framework may
> cause too big side-effects of debugged aplication run.
That's what venkman and Firebug do, and it seems to work out fairly well.
- --BDS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKr6SFSSwGp5sTYNkRAp17AJ9R6gdxVKQuW+2OxL1aoham0HoaOACgx6xI
df5138+RCht6K5dPUa3/Row=
=kfPN
-----END PGP SIGNATURE-----