The Inside Track on Firefox Development.
« March 2004 | Main | May 2004 »
April 25, 2004
Branch Life
Now that we're going to be living on a branch for a fairly long period of time (up until Firefox 1.0 - late summer) with development and testing continuing on the trunk, we need to rethink the Tinderbox setup.
What I'm thinking about is something like this. For each platform:
- A slower tinderbox to do an alternating cycle branch/trunk clobber build and release binaries using the post-mozilla-rel script. This can be the only branch tinderbox if necessary - speed isn't as important here since the branch isn't taking as many checkins, and the trunk speed isn't as important because we'll also have
- A faster tinderbox to do a trunk depend build. I want to get the newest and fastest hardware on the Firefox trunk build page to get people watching it.
So, as usual we have hundreds of Linux machines so that shouldn't be a problem. After acquiring Moco I now have two Windows machines (the other is Beast). I don't know which will be doing what yet... Beast may become our depend build since it's got higher performance components and a faster clock rate. For Mac right now we have Imola, an 867MHz Quicksilver G4 - I'd like to get that doing the alternating cycle and have the 1.6GHz G5 that chofmann bought recently for smoketesting become the trunk depend tinderbox.
Posted by ben at 6:18 PM | Comments (5)
More SmartUpdate Screenshots
Posted by ben at 3:32 AM | Comments (22)
April 24, 2004
A Call To Arms
Mozilla has always been concerned with finding new talent - this is important not only to reach new goals in the codebase but because the set of people working on the project changes over time, and when someone steps down a capable replacement must be found.
I was discussing this with Dave the other night - I was wondering how Mac apps always seemed to look so good - not just polished, but decidedly pretty. Dave hypothesized it was because of the relatively large number of graphic designers in the Mac community, with a vested interest in the software that they use, and a desire to make it look better. I think Dave is right.
The best and only way to attract the best talent, in my opinion, is to strive to create top notch products that encourage like-minded folks with ability and dedication to participate. I like to think that this has been the case thus far with new-generation Mozilla browser products like Firefox and Camino which have attracted a much more diverse set of contributors (such as the members of our Visual Identity Group) that Mozilla's older generation of applications may not have reached.
I'm firmly against outreach programs - anyone who needs their hand held in order to contribute is not someone that I think can be a mover in this business. Mozilla's key contributors are highly motivated, talented, dedicated individuals who are largely self-taught. Every so often a new person like this pops up and it's great. I don't mean to demean the value of simple patchmakers - but Mozilla really needs a stock of resources willing and able to design and implement large scale features. These people need to be able to take on existing components and not just own them idly but bring them forward. It's only by this means that Mozilla can remain at the cutting edge, and remain relevant.
As a side note, part of what I think creates a great engineer is someone who thinks about what is possible, rather than what isn't. That might sound cliched, but it's true.
Mozilla needs more talented people in all areas, but especially:
- User interface design and implementation
- Documentation for new developers (I realize highly detailed documentation on a project with as lean a resource budget as we have is a fool's errand, but some more module layout/interaction maps would be good - offering developers an easy way to navigate the code base while they're learning it and allowing them to answer more of their questions for themselves rather than rely on the attention of experienced engineers whose time is needed elsewhere).
- Product Marketing with a true consumer focus and an understanding of that consumer market, their desires, motivations, and so on. These traits are similar to those required of good UI designers.
- New Applications Developers - people with good ideas and an appreciation of our technology platform and a desire to build interesting new applications on it. Our current crop of applications suits the needs of a good many of today's consumers but what about tomorrow? How will we be ready for tomorrow if we don't have people thinking of new things, stressing aspects of the codebase that our current apps make little use of in new and interesting ways, and so on.
If you want to help, first believe that you can make a difference - that you can impact the lives of millions of people in a positive way, then find something that interests you, something you might have some skill in. Then find the appropriate channels in which to contribute. Mozilla's products will be better for it.
Posted by ben at 3:34 AM | Comments (36)
April 23, 2004
Extension/Update Manager Screenshots
Posted by ben at 3:29 AM | Comments (20)
April 21, 2004
Web Service Joy, The Ongoing Saga
The best thing - the absolute best thing - about working with Mozilla's web services implementation is that when you encounter a bug, and find a way of working around it, another bug hiding underneath is waiting to bite you. Well, after sitting down with Darin for over 2 hrs I finally have a solution that works acceptably for my Extension Update mechanism. The bug fix was an incorrectly offset DOM element - a one word patch. Sigh. Thanks Darin for the help otherwise I'd surely still be stuck.
Despite the convoluted nature of their use from client-side javascript, I'm nonetheless enamored of the power and potential of writing rich clients using WSDL/SOAP. It certainly seems like there are a number of interesting apps that could be built on this technology. The real stumbling block now is Mozilla's implementation, which has been described diplomatically as "lightly tested." In reality it seems to be more the case that the code was made to compile on all platforms, and then checked in. What's really needed now is a comprehensive test suite of features that real world applications are likely to want to use (complex types as parameters and return values, arrays of complex types as parameters and return values) and various server configurations and such like using both interfaces - the WSDL wrapper to SOAP and using SOAP directly. It's only by developing a test suite and then bringing the implementation into compliance that the feature will become truly useful. At the moment, with Darin's fix it is slightly better than a toy. ;-)
Posted by ben at 2:24 AM | Comments (5)
April 20, 2004
Smart Keywords Get Smarter
I've just checked in support for http-POST style forms and smart keywords - basically now you'll be able to associate smart keywords with forms that use the POST method instead of GET. Just use the UI in tomorrow's builds as you would to add a keyword to a GET form. The storage of the information in the bookmarks file is slightly different - the data is stored in a POST_DATA field on bookmarks items, application/x-www-form-urlencoded with the user field replaced with %s, like the appropriate field in GET urls.
Enjoy!
Posted by ben at 3:11 AM | Comments (5)
April 19, 2004
The Plan
- Create new weblog to talk about development of Firefox web browser.
- ???
- PROFIT!
(note: stock stylesheet is preliminary)
Posted by ben at 2:14 AM | Comments (7)
April 18, 2004
New Tinderbox
I went out and bought a new tinderbox for Firefox today - I call it Moco, an Athlon XP2600 that will be doing (initially) branch nightly and tinderbox builds this week and then transition to doing trunk/branch depend builds later on.
Posted by ben at 9:36 PM | Comments (3)
April 8, 2004
What I Learned About Web Services
Some info, links and other details about writing and deploying Web Services on Windows:
Posted by ben at 5:41 PM | Comments (1)
April 3, 2004
Web Services Baby
The observant among you will know I'm putting together Firefox's new extension manager. For the update checking I had been planning on encoding each extension ID (which is presently a GUID) into a URL supplied by the extension or if not supplied, the client (in this case Mozilla's update server) and loading the URL as a RDF datasource.
This seemed like a bit of a kludge though as it was possible that you could build up huge URLs that might eventually push the character length limitations of URLs... and also not be that scalable or understandable.
Thus I decided to write a web service to do update checking with the server. I haven't actually written that service yet but I've created a simple test service and it works. Yay.
Posted by ben at 1:06 AM | Comments (11)
©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by
Jon Hicks, and is a
trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz
