by Stephen Shankland
Mozilla is building a number of features into the upcoming Firefox 3.7 browser--but the organization now has begun stewing over whether to introduce some of them in a significant update as planned or to rewrite some sooner for a variation of the current browser.
Programmer Benjamin Smedberg proposed the retrofit approach with a version called Lorentz on a Mozilla mailing list in late December. In the resulting discussion, developers and observers weighed the tactical advantages to each approach and wondered whether the quickening pace of Firefox development is ill-suited to browser users among businesses.
Firefox is based on a browser engine project called Gecko. The nearly complete (but somewhat tardy) Firefox 3.6 is built on Gecko 1.9.2, and the Firefox 3.7 is set to use Gecko 1.9.3. The question afoot is whether to "backport" significant Gecko 1.9.3 features to 1.9.2 and release the new Lorentz version of Firefox based on it.
"With the [Lorentz] project branch, I believe we could go to beta in the middle of January and release in late March/early April," Smedberg said. In contrast, "doing a release from mozilla-central/1.9.3 presents a lot of schedule risk without matching reward."
One feature in question is out-of-process-plugins (OOPP), a design change that moves plug-ins such as Adobe Systems' Flash to a separate computing process--and a project Smedberg is involved in. The work, the first phase of a Mozilla project called Electrolysis, is expected to improve stability; many browser crashes are the result of problem with Flash programs. Another feature he'd like is a less disruptive browser update process--a particularly relevant technology given Mozilla's attempt to move to a more frequent release cycle.
Some at Mozilla would like to see a few new features added to the nearly final Firefox 3.6 rather than wait for a later, more substantial update.
(Credit: Mozilla)
Chris Blizzard, who runs Mozilla's developer relations, sounded supportive of the Lorentz plan and added some features he'd like to see included sooner rather than later, including faster Direct2D-based graphics for Windows machines, CSS transitions that can add pizzazz to some graphic elements, and Web Sockets for communication between a browser and a server.
But, he added, delay is a risk of new features. "We need to make sure this train doesn't get too big, though, or it will stretch out into a pretty long release," Blizzard said. Indeed, that's what happened with Firefox 3.5, which began as a quick 3.1 update but arrived months later as more features were added.
Added L. David Baron, "I have bad feelings about this plan based on the last time we did this: Firefox 2.0 sucked resources away from the trunk [the development of new version of Gecko] and allowed it to become extremely unstable, and it look a long time to get things back together for Firefox 3."
Eventually the discussion turned to how well corporate users are able to deal with a fast development cycle.
"The nature of the Web doesn't really lend itself to long-lived stable browser branches, IMHO," said programmer Robert O'Callahan. "A lot of the security issues we discover in the Web itself require proactive security measures such as UI [user interface] and architectural changes that one normally wouldn't apply to a 'stable branch.'"
John J. Barton, an IBM programmer who involved with the Firebug extension to Firefox to aid Web developers, made the case for relatively rapid changes.
"IBM and our customers are all moving to faster development cycles," Barton wrote. "That's why I urge Firefox team to continue to lead in that direction."
Originally posted at Deep Tech
0 komentar:
Posting Komentar