MozillaZine

Neowin.net Interviews Lead Mozilla Firefox Developer Ben Goodger

Thursday May 27th, 2004

Tom Graham of Neowin.net writes: "Ben Goodger, chief developer of Firefox, has kindly taken the time out of a busy schedule to have a second chat with Neowin.net. Development of Firefox, XUL and the future of Firefox all come up with some interesting answers. Read on for an interesting interview, and thanks again to Ben for taking the time."


#1 XUL Runtime Environment

by nicodietrich

Thursday May 27th, 2004 3:37 PM

Reply to this message

From the interview:

"One thing we eventually want to pursue is a "XUL Runtime Environment" that is independent from any particular application front end whereby just the application level components (front ends) can be downloaded. In that instance the browser might be only 2MB if you already have the runtime installed. Thunderbird might be as small as 4MB."

Great! I'm really happy to hear about that, since the increased size is the only disadvantage I see when splitting Seamonkey into Fx, Tb & Nvu. This step also makes it more attractive to create stand-alone applications using the Mozilla platform! (and not having to bind them to a browser or an email client!)

Really great to hear, hope that'll be realized soon (for 2.0? or even earlier?)

Nico

ps: Will the SVG engine be part of this XUL-RE or only of the browser? I hope it'll be included in the base system, so it can also be used for stand-alone apps.

#4 Re: XUL Runtime Environment

by Gnu

Friday May 28th, 2004 2:11 AM

Reply to this message

Would this also, in theory, decrease memory usage for Mozilla applications sharing the runtime when running simultaneously?

#5 Re: Re: XUL Runtime Environment

by leafdigital

Friday May 28th, 2004 3:11 AM

Reply to this message

Yes, it should. I don't know specifically about the XRE plans but operating systems load memory blocks marked as 'code' (read-only) only once, mapping them into the memory space of different processes that may need them. So if the program is loaded from some of the same DLL/EXE files (or Linux, Mac equivalents) as another program, you should save code memory correspondingly.

There would probably be no saving in data memory (depending on how it's implemented of course; it is *possible* to share data between instances, but this could potentially lead to problems such as one app crashing the other one, which is sort of what separating them was supposed to avoid). So I wouldn't expect large savings - I don't know how much shared native code there is in TB/FB but I would guess only a few megabytes.

By the time XRE is a reality (2005 hopefully?) memory may be less of a consideration for most people, mobile devices excepted. That said, Mozilla suite isn't exactly the smallest application in the world, nor is Thunderbird...

Interesting article, by the way - I already knew about the much-needed theme/extension-update work, which is good, but I haven't really been paying attention to the Fire* download size. If they get it down below 5 MB that's rather impressive.

I might finally switch to Firefox in 0.9; it's a little irritating to have to install extensions to browse the way I want (no tabs), but I believe said extensions do now exist. Other than that and a few other UI problems, my main issue with FF is that it still seems a bit ropey, and I guess more testing would help that. (uh, do they have talkback? Surely not in that 5 MB...?)

--sam

#7 Re: XUL Runtime Environment

by sipaq

Friday May 28th, 2004 4:45 AM

Reply to this message

> (uh, do they have talkback? Surely not in that 5 MB...?)

Yes, talkback is included in the 4.6 MB installer builds. The zip builds are much larger (5.9 MB) at the moment, because they don't use the new compression algorithm (7zip) which is used in the installer builds.

It should also be noted that the decreased download size also goes for the Thunderbird installer which went down to 6.2 MB from 8.4 MB.

#9 Not necessarily.

by robdogg

Friday May 28th, 2004 1:23 PM

Reply to this message

>>Yes, it should. I don't know specifically about the XRE plans but operating systems load memory blocks marked as 'code' (read-only) only once, mapping them into the memory space of different processes that may need them. So if the program is loaded from some of the same DLL/EXE files (or Linux, Mac equivalents) as another program, you should save code memory correspondingly.<<

I don't think this is how the OSes work. Memory blocks are never shared (other than core os) just for the reason if one app manages to kill a lib, it doesn't take other apps depending on the lib with it. The memory blocks are marked as code, so that they can be quickly copied should another app need them, negating the need to load the code from the hard drive. Otherwise, Visual Basic 6 programs would take very little memory since most of the stuff in VB is handled by the runtime.

#10 Re: Not necessarily.

by bzbarsky

Friday May 28th, 2004 2:40 PM

Reply to this message

> Memory blocks are never shared (other than core os)

That's incorrect, for modern OSes.

> just for the reason if one app manages to kill a lib,

You don't kill code. You kill an entity called a process. Multiple processes can all have the same physical memory mapped into their virtual memory areas, with the physical memory holding the library code. If a process dies, other processes are not affected.

Note that virtual memory mapping is not at all the same as copying.

> Visual Basic 6 programs would take very little memory since most of the stuff in VB is handled by the runtime.

There's a difference between static footprint (the size of the code) and dynamic footprint (the size of the process data structures). The latter are not shared across processes, typically.

#2 "XUL Runtime Environment" ???

by peterlairo <Peter@Lairo.com>

Friday May 28th, 2004 12:20 AM

Reply to this message

"One thing we eventually want to pursue is a "XUL Runtime Environment""

Is that the same as "Gecko Runtime Environment" (GRE)? I thought it has been referred to as GRE for the longest time. :-\

#3 Re: "XUL Runtime Environment" ???

by dave532

Friday May 28th, 2004 1:27 AM

Reply to this message

As far as I know the XRE would be a superset of the GRE, the GRE just containing the core Gecko components that apps can link against in the standard way. Whereas the XRE would basically be a runner for XUL so you just have to distribute the xul/js/etc files without any need for compilation.

This would lower the barrier for entry as you could create your own standalone apps without the need of a compiler

#8 Re: Re: "XUL Runtime Environment" ???

by buff

Friday May 28th, 2004 5:40 AM

Reply to this message

The XRE should get integrated into Gnome or KDE so no installation is required to run new XUL apps. That would be a serious advantage to using Mozilla as an application framework. It would be easy and cool to make little desklets in XUL/JS that perform simple functions.

#6 Re: "XUL Runtime Environment" ???

by mlefevre

Friday May 28th, 2004 4:30 AM

Reply to this message

Well not that long, the GRE was called the MRE (M for Mozilla) until about 18 months ago.

But it's not a new name - it's more than just the GRE. More about it at <http://www.mozilla.org/projects/xul/xre.html> (and at the bottom there's a link to an even older doc where the XRE was going to be based on the MRE rather than the GRE). As you can see from that page, it's at the stage of discussions and plans, rather than anything concrete yet - although Ben has mentioned several times that it's one of the things he's been spending some time thinking about.

#11 Reply

by Dizzle

Friday May 28th, 2004 9:38 PM

Reply to this message

Maybe it's because I'm tired right now. But I'm sick of people talking about download size. Mozilla takes less than a minute to download. After installing I still have gigs upon gigs of space. When I copy it to a USB stick there's still room. I put it on a CD once and had tons of space left. I transfered it over the network and it took a matter of seconds. I burnt it to DVD and it doesn't even fill one circle.

browsing speed, memory usage these things matter. Download size. Get a life.

#13 Re: Reply

by Gnu

Saturday May 29th, 2004 12:48 AM

Reply to this message

Download size still means a lot to a lot of folks, and can potentially turn people away from trying out applications. You and I may not think anything of pulling a 10MB file, but folks on dial-up or worse will give it a miss if they feel "comfortable" with the products they already use, not being willing to have a go at a better alternative if it's inconvenient. High-speed connections are hardly with the worldwide majority of users, so size matters a great deal.

#14 Re: Re: Reply

by Ben_Goodger

Saturday May 29th, 2004 1:53 AM

Reply to this message

Even for folks on broadband, mozilla's servers aren't the fastest in the world. The smaller download size makes a noticable difference, especially to testers/community QA

#15 Re: Reply

by buff

Saturday May 29th, 2004 8:39 AM

Reply to this message

Dowload size is very important to me. I am connecting to this forum using dial-up earthlink! I also like small application sizes since they launch faster in KDE and Gnome. The Mozilla suite takes a couple of seconds to appear for me while Firefox lauches in about a second. Ben you are the man! Less truly is more.

#18 Re: Reply

by Smigit

Tuesday June 1st, 2004 4:15 AM

Reply to this message

it takes me two-three hours to download. Im on dialup on a pair gain line. so its an issue, aklthough it doesnt stop me using it by any means and i wouldnt criticise it myself as a major issue.

#12 size ... mem

by kwanbis

Friday May 28th, 2004 9:42 PM

Reply to this message

the funiest part is that IE wights like 60 MB to download ...

#16 [nt] want your favorites--mozilla 1.5a and above.

by smkatz

Sunday May 30th, 2004 8:39 AM

Reply to this message

IE has a download manager (yes, I know so do we..) but we don't actually encourage the use of it. Maybe we should. (the Net Installer).

#17 Re: [nt] want your favorites--mozilla 1.5a and abo

by EyesOnly

Sunday May 30th, 2004 11:26 AM

Reply to this message

While it's true that we have a similar "download manager"/Net Installer, I was always told that it wasn't encouraged to use it because it often created "buggy" installs. The one time that I downloaded it from the FTP site just to test it that's just exactly what happened to me (I forget the version number) in that it failed to copy a number of files for the upgrade. Perhaps if some time could be placed into that as well it would make upgrading much, much, easier while still working towards reducing the over-all download size. Then upgrading for those people who aren't especially "net savvy" would definitely be a less painful experience. Possibly even more people would seriously consider changing from their current browser (maybe IE?) to our products?

I realise programmers and resources are stretched pretty thin as it is right now. But even if a few good minds could work on such a project I wonder what they could accomplish? If I hadn't have lost my programming experience in an "accident" I would've loved the challenge. Ah well...

#19 that's odd...

by fishbert

Tuesday June 8th, 2004 4:46 PM

Reply to this message

Am I the only one who finds it a little funny that the new theme and extension managers are listed under "stability" in the article? =)