Neowin.net Interviews Lead Mozilla Firefox Developer Ben GoodgerThursday May 27th, 2004Tom 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." 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. Would this also, in theory, decrease memory usage for Mozilla applications sharing the runtime when running simultaneously? 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 > (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. >>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. > 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. "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. :-\ 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 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. 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. 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. 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. 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. the funiest part is that IE wights like 60 MB to download ... 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). 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... 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? =) |