Slashdot Mirror
Mozilla's Major New Roadmap
kerz writes "mozilla.org today released a new version of it's famed roadmap, this time with some pretty major changes. First and foremost, they plan on ditching the large Mozilla suite in favor of Phoenix and Minotaur. Secondly, they have plans to change the milestone cycle to allow for more time to fix the Gecko layout engine to be smaller and more efficient. MozillaZine has the scoop..."
1.Switch Mozilla's default browser component from the XPFE-based Navigator to the standalone Phoenix browser.
2.Develop further the standalone mail companion application to Phoenix already begun as Minotaur, but based on the new toolkit used by Phoenix (this variant has been codenamed Thunderbird).
3.Deliver a Mozilla 1.4 milestone that can replace the 1.0 branch as the stable development path, then move on to make riskier changes during 1.5 and 1.6. The major changes after 1.4 involve switching to Phoenix and Thunderbird, and working aggressively on the next two items.
4.Fix crucial Gecko layout architecture bugs, paving the way for a more maintainable, performant, and extensible future.
5.Continue the move away from an ownership model involving a large cloud of hackers with unlimited CVS access, to a model, more common in the open source world, of vigorously defended modules with strong leadership and clear delegation, a la NSPR, JavaScript, Gecko in recent major milestones, and Phoenix.
6. ???
7. Profit!
Ok, I admit to adding 6 and 7.
Trolling is a art,
If you're referring to the
Either way it's not Mozilla's fault since it is as modular as the user or the install script tells it to be. If you choose to install everything including the kitchen sink you can hardly complain of bloat when you get what you asked for.
(Took me a minute to figure this out... Minotaur? Thunderbird? What?)
My experience of Opera's stability is quite the reverse, however. Moz hardly ever crashed. Opera crashes a couple of times a month. The difference is that when I have a load of tabs open in Moz and it crashes I then have to hunt for all the pages I was looking at. With Opera it lets me continue from exactly where I was pre-crash. I now tend to not bother with bookmarks, just open pages that are interesting in a new tab, move that tab to the left of my current active tab and leave it there. For sites like /. I tell it to refresh the page every 15 minutes, and I can see at a glance if there's any more news.
I am TheRaven on Soylent News
Two of your three problems are solved. Mozilla's mail client now remembers the last selected message in each IMAP (and POP too, I presume) mailbox, and you can configure it to send plain old text messages.
The latter feature has been around for a while; the former feature is relatively new but is definitely in 1.3.
I agree with you, but did you RTFA?
Deliver a Mozilla 1.4 milestone that can replace the 1.0 branch as the stable development path, then move on to make riskier changes during 1.5 and 1.6.
(...)
the reasons for this new plan are:
1. Phoenix is simply smaller, faster, and better -- especially better not because it has every conflicting feature wanted by each segment of the Mozilla community, but because it has a strong "add-on" extension mechanism. (emphasis mine).
The idea is not to "drop" the suite, but to make it modular instead of hardwired.
Prescriptive grammar:linguistics
Development in Phoenix has hardly stopped. They just haven't released a milestone in a while. Pick up one of the nightly builds and you will be *Amazed* at the advances over the .5 release. Not only is it quicker and lighter, it's vastly prettier and has some really good end-user functionality features such as collapsable preferences.
.68 build. Damn, there's a lot of reasons to use Phoenix instead of Moz right now.
I've been using the April 1 build all day today... heavily... and it's been holding up like a champ. If I were going to compare this in terms of version numbers, I'd call it the
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I use Phoenix and IE all day long for web development and personal use. While Mozilla/Netscape cannot start as fast as IE, Phoenix is quite capable of doing so. Phoenix is only on version 0.5 right now and it crashes less than IE (a few times each week). As for page transitioning, someone can make an extension to Phoenix to handle these proprietary tags, but I don't know why they'd want to... they're not standard HTML, they're annoying, and they slow down the browser. So, I suggest trying Phoenix instead of Mozilla and THEN compare the two.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
As for upgrading things seperately. Yes, you could do this already assuming anyone had the time to maintain the mail/news and browser components seperately. Unfortunately they don't but this is a packaging issue rather than any inherent flaw in Mozilla. You'll find lots of independently maintained modules of Mozilla on mozdev.org such as the spellchecker, so obviously the technology supports it.
Furthermore, Mozilla is moving towards the GRE model, so perhaps what you desire is closer than you think. The GRE is the Gecko runtime shared by all applications. The plan is to distribute one copy of this in a well-defined manner and allow applications to utilise the existing GRE much like the way the JRE works now. I don't know how far along this is, but GRE nightlies have been a common feature for a while now. I expect sooner or later Mozilla will become a GRE client itself and anyone want to use Gecko in their app will point their users at the GRE or detect the one they already have installed.
As for Opera's "clean, intuitive" interface (another claim from your page), you might check out Matthew Thomas' claim that Opera is the only UI worse than Mozilla's.
Have you looked at XUL's tree widget?
h tm l
http://www.xulplanet.com/tutorials/xultu/trees.
Unless you're trying to run Mozilla on a freaking Pentium 100 with 64 megs of RAM or something else antiquated like that, performance is fine
:).
I beg to differ. On my other system, a 433 with 256MB of RAM, Mozilla is a pig. Pure and simple. It takes close to 30 seconds to load sometimes, and page rendering makes me feel like I'm back on 14.4 dialup. Contrast this with Opera, which loads in a second or 2, and renders pages as soon as they're downloaded (in fairness, I won't mention how fast IE is, because they cheat and preload most of the browser when the system boots
Now that I have an 1800XP, you're right, Moz is pretty zippy. But it's pretty sad that I'd need almost 2ghz of effective performance just to render some html.
I won't even talk about how long Moz takes to load on the Redhat box (p2-266, 256 RAM). Let's just say Galeon beats it by an order of Magnitude. Same renderer too, so just what's causing the delay? Oh yeah. Bloat.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
All large, mature codebases are messy -- that's a true fact of life in the real software world. Maybe they don't teach that in school yet. They should.
.... Hacking all that on top of the old codebase cleanly could be done, but it would have taken a ton of effort -- assuming we could've found anyone interested in doing the work.
Gecko is less messy than the old, MozillaClassic codebase. It's still messy -- it must be so, remember, because it is real. Plus, many hands have handled it. Also, it was over-designed a bit, or a lot, in places -- but that's water under the bridge.
Gecko does a *lot*, way more than the old codebase. HTML4, CSS1, CSS2.1, parts of CSS3, DOM levels 1-3, XML, XSL-T, SVG, MathML, SOAP, WSDL,
True statement: the reason we ditched the "Netscape 5" code was not because it was messy. The reason was that we simply could not interest enough new people, inside or outside of Netscape, in learning to deal with the mess, and then clean it up, and furthermore build on top of it. Almost all of the "old people" who wrote that codebase had moved on to other things.
Someone please mention this overriding non-technical fact to http://joelonsoftware.com. Joel may be right to call all the newcomers who were unwilling to work on the old codebase "undisciplined" or "unprofessional" -- if those words are fair, then all I can say is that there are not many disciplined professionals in software to be found. I worked on both codebases extensively (I created the DOM "level 0" along with JavaScript in 1995, for Nav2), but I can't claim to be either disciplined or professional.
Meanwhile, during 1998, Netscape had a team working on the "NGLayout" project, and they wanted to contribute that new layout engine. We (mozilla.org) took a chance, preferring the new frontiers of that codebase to the crowded, overdeveloped old world. The lure of the frontier, the chance to homestead your own plot, especially using XML and JS, was what mozilla.org needed most in order to attract contributors. People simply could not sink the costs required to learn the old C/C++ codebase enough to scratch their itches.
Our gamble worked, I think. Not without many bumps along the way (and whose idea was shipping Netscape 6, anyway? Not mine!). Now, our top Gecko hackers are people such as dbaron@dbaron.org, who has recently graduated from Harvard, and who is an invited expert on the W3C CSS working group; rbs@maths.uq.edu.au; and bzbarsky@mit.edu.
Yeah, it took too long. There are no shortcuts. We should have done better. But doing "just a browser" was never in the cards, and not only because of Netscape's commitments. Mozilla is and always will be more than "just a browser". As jwz wrote here a while ago, if you want just a browser, stop whining and go use Konqueror, Galeon, K-Meleon, or any of a number of choices, depending on your preferred platform. (Don't kid yourself that Mozilla could have stopped IE's distribution-channel-based takeover, no matter what we did.)
If you want to help Mozilla, please come join us. With the new roadmap, we have more new frontier land to develop.
"what exactly is happening to XUL?"
Short answer: nothing; sorry we mentioned it.
Longer answer: we brought XUL up because if we "switch to Phoenix" from the app-suite browser, based on Phoenix as it has been distributed so far, we drop Mac XUL support. We don't want to do that. So in the roadmap, we go out of our way to say that we *are* going to build Phoenix for OS X, when we switch.
I wonder how we can make this simple point more clear, without inviting confusion. Jumpy roadmap readers seem to skim, and fly off the handle out of fear that we're dropping XUL, or something silly like that. Rest assured, we are supporting XUL fully.
XUL with some form-submission smarts, but using XML-RPC, SOAP, WSDL, or whatever's appropriate, should become the basis for web applications. XUL widgets should form the kernel of a pragmatic XForms implementation. And XUL's still great for cross-platform applications. We like XUL too.
I use the integrated suite every day -- mostly the browser, mail/news, and message compose. Before any change to the default build, we'll make sure that this mode of operation is possible if you configure mail (Thunderbird, I mean) as an add-on to the Phoenix-based browser.
Remember, your add-ons persist across upgrades, unless an incompatible change to the new toolkit (which is XUL, XBL, JS, and CSS) invalidates a particular add-on (in which case, you'll need to get the new, compatible version of that add-on once it's out; this kind of invalidation should not happen often). So once you've added the mail extension to the browser, you're set -- you should be able to operate just as you do today with the integrated app-suite.
That's the goal, anyway, and a requirement to meet before we switch the default build.
The guy at phrasewise is, frankly, an idiot.
Speaking, btw, as a former Opera user who now uses Mozilla instead, on all platforms.
Let me review a few of his points:
This is to some degree debateable whether or not the underlining thing is really a good idea or not, but it's certainly far better than the ridiculous button mimicing, and many think that it's a good idea. At any rate it's certainly hard to see how such an unobtrusive feedback mechanism could be objectionable (especially as I believe it can be turned off.)
Well, fair enough, to start with. It probably wouldn't be a bad idea to redesign those menus a bit, on the other hand, in comparison to say, IE, I will defend them - it's far better to have an arguably over-complex menu than to simply eliminate the functionality entirely, which is what IE and to a lesser degree Mozilla do in comparison. But if he stopped here he'd have grudging agreement... but that he does not do.
This is just wrongheaded. Having used it, I can testify that having those two options seperate is a big usability gain. If it were a checkbox on the save dialogue, for instance, there would be considerable wasted time on each save where it needed to be toggled - which for some of us very often. Now, if you use only one or the other it would make sense to do it the way he suggests - but when you remember Operas core audience it's clear they made the right choice here.
I actually agree with this one, but it's hardly a major criticism - usability reviews are often heavy on nit-picking but this has to be one of the smallest nits I've seen picked in quite awhile. Small mistakes like this certainly don't justify the scathing tone of the review, particularly when he's comparing Opera to IE and Mozilla, both of which make far more serious mistakes.
Both factually incorrect and wrongheaded.
Factually incorrect because Opera doesn't insist on MDI anymore, it can be set to run in MDI or SDI at the users preference, and because Microsoft didn't invent MDI - it was used long before they got ahold of it.
Wrongheaded because it's relying on fallacious reasoning - even if the factual errors were correct that still wouldn't mean that MDI shouldn't be used in a browser. Many (including me) find it to be one area where MDI is really useful. So many, in fact, that Mozilla and most other browsers now implement a half-assed copy of it, so-called 'tabbed browsing.' Those that don't like MDI, of course, can still use Opera and simply set it to SDI mode, so no criticisms based on MDI really hold water anyway, regardless of whether or not you have some sort of religious aversion to it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
You're right about KHTML being the better open source alternative for Apple. I would have made the same decision, were I in the Safari team's shoes a year ago, operating under the constraint of secrecy, having to hire a team who didn't know either KHTML or Gecko, and had to learn one or the other from scratch.
(Of course, I wouldn't want to work under those constraints, if I had the choice.)
I apologize if I misread the original post. Lately there has been a lot of "Apple picked KHTML, so Gecko must be deficient in all situations" talk -- but we agree that's fallacious.
Your second point misconstrues mine about Apple being prepared to carry its tine of a fork. My point is that Apple management wanted to develop in secret, which decision inherently risks a fork.
Netscape has not done that. Almost all of its MPL'ed changes, certainly all to the core Gecko code (not necessarily all of UI changes under xpfe -- but most of those, too) go into cvs.mozilla.org early and often. They don't hide behind a firewall in a commercial source tree for a year, while the open source they're based on diverges.
MPL vs. LGPL had nothing to do with the point I was making. Anyone willing to publish diffs or distribute them along with programs can perpetrate a fork of code provided under either license.