Major Roadmap Update Centers Around Phoenix, Thunderbird; 1.4 Branch to Replace 1.0; Changes Planned for Module Ownership Model
Wednesday April 2nd, 2003
In the most radical change to the Mozilla project since the late 1998 decision to rewrite much of the code, mozilla.org today announced a major new roadmap proposal that will see Phoenix and Thunderbird (also known as Minotaur) becoming the focus of future development. According to the roadmap, 1.4 is likely to be the last milestone of the traditional Mozilla suite and the 1.4 branch will replace the 1.0 branch as the stable development path. mozilla.org is also proposing changes to the module ownership model including a move towards stronger leadership and the removal of mandatory super-review in some cases. Please click the Full Article link to read the full analysis.
This is excellent news.
this is exactly what i was hoping mozilla.org would do. i really like phoenix, but never use it since i use all the other suite addons constantly (especially dom inspecter, venkman, mail and composer) ... i'm *very* excited about this.
Me too. I keep using reg. mozilla because phoenix hasn't been as well supported and always been on the backburner. I have and never will use stuff like composer and the irc chat and would prefer to use just a slimmed down browser and mail client.
#68 only if there is feature parity
Wednesday April 2nd, 2003 11:48 PM
I would hate to see features or configuration options disappear because of this. I still prefer Mozilla a lot, because I regularily use both browser and mail, so have it in one app is nice, and because it has more config options and features than Phoenix.
#85 Re: only if there is feature parity
Thursday April 3rd, 2003 3:34 AM
Take phoenix (or phoenix like system) doesn't mean we remove all the best out of the mozilla-the-suite ... so phoenix will become the missing options and features ;-)
#128 Re: only if there is feature parity
by Assimil8or <email@example.com>
Thursday April 3rd, 2003 11:15 AM
If I understand things correctly most (if not all or even more) features will be available after a while as extensions (even mail can be an extension of "phoenix" =))
#137 Re: only if there is feature parity
Thursday April 3rd, 2003 12:50 PM
No. It's critical they strip out little used, dumb or unstable features. They are the whole reason Moz is (accurately, imo) considered to be bloated.
#146 I can't hear that old 'bloat' rant anymore
Thursday April 3rd, 2003 3:44 PM
If there are people who are overcharched by a couple of buttons or options, fine, give them something like the embedding-demo which consists only of the rendering area and an url bar. I want a tool that allows me to do my work flexible and efficiently. Mozilla is still lacking a couple of important features and Phoenix is lacking *a lot* of features and configuration options. I am all for making the UI better suited to all levels of users, but simply stripping of features is not the way to go. What is going on - are the Jenny Craigs of the world conspiring here?
I'm sure I'm not alone in thinking that this is a fantastic development. I thought it would never happen, though, because of corporate influences such as Netscape/AOLTW bogging down the innovation process. I am relieved to see that the Mozilla.org drivers are able to put these influences behind the innovation, health, and success of the organization as a whole.
I have to wonder, though, what this means for Mozilla.org's relationship with those vendors. Will Netscape be (hopefully) following suit and using the new toolkit-based applications for future versions of their suite? Or will they continue to develop indepently off a fork from the 1.4 XPFE branch? How will this affect the way in which the developer resources Netscape provides are assigned?
Isn't AOL/Netscape already going that route with Communicator?
The Mozilla plan started to make sense to me with Midas, Composer (like Outlook Express's activeX extension) has become vital to many websites.
<http://www.sitemason.com> that RTE article we just saw recently.
How does this affect Midas? Badly, I would assume.
Wish I could learn coding in 24 hours.. in a year's time, maybe.
Why should this affect Midas? Midas is a backend thing and, as such should be entirely unaffected by what is essentially as User - Layer shift. In the unlikely event that there is a problem with Midas in phoenix, Brendan and Hyatt stated that work would be done on the areas where Mozilla development had outpaced Phoenix.
I also wonder about this, Phoenix has no composer and thats why Midas doesnt work, so If everything is conentrated on Phoenix that doesnt have the composer, how will Midas work?
By using the editing abilities of Mail/News (Thunderbird), after all what made Composer a reality was that a lot of the backend work was done for Mail/News anyway ... if IIRC, that was one of the rationales for the Composer project.
If "a lot of the backend work [for Composer] was done for Mail/News" and "the editing abilities of Mail/News, [the backend work for Composer]" will be needed to enable Midas in Phoenix, then what is the advantage of breaking up the suite.
That argument seems to suggest that the mozilla suite is actually greater than the sum of its parts!
Mozilla is nothing more than an experimental thing to the AOL/Time Warner people. Whatever looks promising there, they take it & put it into the latest Netscape release. All this stuff won't change anything for their Netscape division.
PS: When is AOL/Time Warner switching their AOL browser over to the Gecko-based browser engine? Come on, people!! Break those Microsoft ties once & for all!!
#39 Re: How does this affect vendors?
Wednesday April 2nd, 2003 4:56 PM
Netscape's browser has always picked one milestone (the stable branch) and then released their Netscape branded releases for the next few months based on that.
eg (If I'm remembering the numbers right) the preview releases based on M18/ 0.6 and then the final Netscape 6.0 released off the Mozilla 0.6 branch. Every Netscape after this was essentially just a small set of bugfixes to Mozilla 0.6 up to Netscape 7.0 which was based on Mozilla 1.0, now Netscape's subsequent releases have all been based on the 1.0 stable branch, up to now when the talk is that their next version will be based on Mozilla 1.4 final.
Netscape will probably then stick to releasing minor upgrades to Mozilla 1.4 (note that the timeline does specify that 1.4 will be a long-lived branch for embedders and 3rd party bundlers) for the next 6-9 months.
In the mean time Mozilla will progress through 1.5 and onto 1.6 with many, many changes many of which have the potential to cause bugs and problems. Only when these problems are all ironed out will Netscape/AOL consider releasing the next major version of their browser suite and possibly basing it on Mozilla 1.something (or will it even be 2.0 by then?).
So Netscape may follow suit but not for a long time yet.
#76 Re: How does this affect vendors?
Thursday April 3rd, 2003 2:33 AM
" I have to wonder, though, what this means for Mozilla.org's relationship with those vendors. Will Netscape be (hopefully) following suit and using the new toolkit-based applications for future versions of their suite? Or will they continue to develop indepently off a fork from the 1.4 XPFE branch? How will this affect the way in which the developer resources Netscape provides are assigned?"
Considering Netscape remains the major supplier of developers, servers and bandwidth, you can be quite sure their opinion would have been a significant consideration!
Funny thing is that months ago I suggested that Netscape should drop using the full Mozilla suite, grab Phoenix and the new AOL Communicator instead and bundled it as Netscape 8 .... well, in reality, am sure I have nothing to do with the decision but am glad this decision was taken.
Some of us did *years* ago.
no no, what you said was they shouldnt develop mail/news/editor apps at all because it would be "a waste of precious developer resources on this crap" ... well, you've been prooved wrong time and time again on this, its utter nonsense.
here a little reminder: more developers != faster development, therefore having some people work on a mail app has no bearing on the people working on the browser app. in fact, it probably sped up the development of gecko and other related technologies as more apps based on them means more testing. just give it up.
furthermore, did you read the road map? did you notice that in fact mail/news/editor etc are all still being developed and supported in the new gameplan as much as they are now? what was your point again?
My point is simple: the development of a suite instead of a browser caused Netscape/Mozilla share to retract and the new roadmap seems to recognize that.
It's is plainly not possible for work on mail to not impact work on the browser. Your contention that it positively impacts the browser effort is the actual utter nonsense...as has been proven time and time again. Why do you think Phoenix "won"?
Except they're still planning to develop and distribute mail, only to give it a second excecutable file. Does the sudden appearance of this second file to click on somehow magically mean that no developers will be working on mail anymore.
Now, as ever, you're not making a lot of sense.
However, from my take on it, it sounds like it will be more like Microsoft and Apple where the browser and email clients are developed by completely separate groups. For example, they would not share a bug database.
Have you ever been involved with software development?
#136 Re: Many they listened to me
Thursday April 3rd, 2003 12:34 PM
I had thought about the new AOL Communicator and downloaded the Beta when it first came out. It crashed my system, so dropped it. Then I heard the official version only worked with AOL, so I forgot about it. Can you configure it to do POP3 with any old ISP?
I saw this news yesterday and breathed in relief as it disappeared.
Mozilla had an excellent amount of bloat to my own taste. Oh, well, time to move on then. It's sad, however since Mozilla kept the old Netscape traditions and everything.
Also, I forgot to add that add-on based architecture is _very_ difficult to manage for localizers since a lot of the addons are not meant to be localized at all and it produces a huge mess. :(
Actually I thought for a very long time that browser-mail-news-composer-kitchen sink was THE RIGHT THING. I used Netscape Communicator until it became unbearably slow, crashy, and not compatible with 50% of the web: until the end of 2000. Then I switched to separate apps for web/mail/news and... well, actually that's good.
I switch to Mozilla (as a browser) when it became stable enough for my use (12 hours a day) at 0.98 and used it until I discovered Phoenix 0.5...
Well right now I launch Moz only once in a while for composer or DOM inspector.... Many useful features are in Phoenix tha mozilla missed; Phoenix is way faster; it doesn't gobble up tons of RAM; and it's not crashy though the 0.5 number was quite frightening (remember Mozilla 0.5? Ph34r!)
#7 Whenever I hear that many buzzwords...
Wednesday April 2nd, 2003 1:28 PM
Whenever I hear that many buzzwords from a consultant, I lock up my wallet and sit with my back to the wall...
"Reset ... around" "Rich" "strawmen". Sounds like the end of Mozilla to me.
Back up those nebulous claims with one iota of fact.
Can't? Well, this is why I modded your Slashdot post down, too. Random inflamitory claim that is not and cannot be backed up equals Troll.
People have been predicting the death of Mozilla for 5 years. It is just plain stupid at this point. Worse that that stupid "Step 1 XXX, Step 2 ???, Step 3 Profit!" crap...
#119 Re: Whenever I hear that many buzzwords...
by vocaro <firstname.lastname@example.org>
Thursday April 3rd, 2003 10:02 AM
Sorry for feeding the troll, but since when do you need to open your wallet to Mozilla? It's open-source software. Also, "rich" is not a buzzword. Neither is "strawmen". It is merely a type of fallacy that the author was trying to point out in his own arguments. See <http://gncurtis.home.texas.net/strawman.html>
Congratulations with a fine decision. This is exactly what I have felt is necessary for the past few months. I'm a full time phoenix user now, mostly because it is way better than the regular mozilla. It's a bold move but it is also a necessary one. Basically people need to get their hands free to do the stuff that is necessary and basically the current mozilla has become an obstacle for doing so. Hence the phoenix and minotaur projects that try to work around this.
I'm sure 1.4 will turn out another fine milestone. I'm also sure most of us are looking forward to 1.5 and eventually 2.0 :-).
Keep up the good work!
#10 Rock on; bout time
Wednesday April 2nd, 2003 2:12 PM
I've been waiting for this. Weird that we find out 1.4 is the last monolithic version at, oh, 1.4 alpha stage, but so be it.
The main reason I resisted Mozilla over IE was the bloat...since I discovered Phoenix, I'm a total convert! Maybe the modular nature of Phoenix/Minotaur can push Mozilla back into the popular use that Netscape enjoyed in the pre-Internet Explorer days! And of course, since AOL are switching to Gecko, this all adds up to a BIG step forward!
"...And of course, since AOL are switching to Gecko....." Really? Where did you hear that from? Would love some links/etc. cheers
How 'bout this?
#52 Re: Amazing!
by willll <email@example.com>
Wednesday April 2nd, 2003 8:18 PM
um. aol 8 is already out. the windows version still uses ie. only the mac version is using gecko.
I beta tested AOL+Gecko a long time and way before AOL8 became available during the end of the summer. That beta test for all pratical purposes died when AOL 8 beta was released. No developements (at least, no public betas) have happened in almost a year.
The only thing I don't understand is why, if the changes are going to be this drastic, they're not calling it Mozilla 2.0? It seems like dropping (or at least deprecating) XUL as a supported interface to mozilla would break the "generally backwards-compatible" implication that calling it 1.x carries.
In no way are the dropping or depreciating XUL, where did you get that from? XUL in one of the most inovated features mozilla has. True, focus will still be set on Camino for the Mac, but XUL is going no where as for as i can tell.
There are no plans to deprecate XUL. In fact, the roadmap says exactly the opposite. Did you read it? :-)
#44 The diagram is not clear to the uninitiated
Wednesday April 2nd, 2003 6:01 PM
The diagram has Mail and Browser depending on the Moz/Toolkit entity, and Mozilla Suite depending on the Moz/XPFE entity. If you equate XPFE with XUL, and remember from the article that the Gargantu-Suite will be retired, it is easy to infer that XUL is being deprecated.
Does Moz/Toolkit use XUL? I am thinking you are saying that it does, and Phoenix / Minotaur will rely on XUL.
#45 Re: The diagram is not clear to the uninitiated
Wednesday April 2nd, 2003 6:11 PM
> it is easy to infer that XUL is being deprecated
Except for bullet #2 in the "what all this does not mean" section....
#103 So what is the difference between Toolkit and XPFE
Thursday April 3rd, 2003 6:42 AM
"Toolkit" implies... a toolkit. XUL is itself a toolkit, so the (apparently unintended) implication is that Phoenix uses a different toolkit. So, what is the difference between what XPFE uses and what Phoenix uses?
#116 Re: So what is the difference between Toolkit and
Thursday April 3rd, 2003 9:59 AM
XUL is not quite a toolkit per se. XUL is a language for describing toolkits.. You can create random tag names in XUL, implement their appearance and behavior via XBL, and then use them.
"toolkit" is a standardized set of XUL widgets that would be maintained by mozilla.org. Pretty much like XPFE is. In fact, the two are very similar in most ways; "toolkit" includes support for customizable toolbars and a few other goodies that "xpfe" does not...
Does that help?
#126 Re: Sounds Great!
by johnlar <firstname.lastname@example.org>
Thursday April 3rd, 2003 10:23 AM
Ultimatly it will be 2.0 probably once it stabalizes, but if this called it 2.0 initally people might think its a new stable branch, I guess they could do an odd number if stable kinda thing, but I think they really want to avoid that road. Anyways here is to hoping they that atleast make some idicaiton that 1.5 is a brand new thing and not to exepect it to be nearly as final a product as 1.4.
> if this called it 2.0 initally people might think its a new stable branch I don't agree, I'd think 2.0 means "this is the first of a new generation of Mozilla builds, so not as mature as the last builds of the previous generation"
Let me soak this in............. I remember when the Phoenix project started "as an experimental browser for mozilla technologies" and the ultimate goal was just this, but I never expected it to be so soon!
This is definitally the right decision for Mozilla. But, I hope that mozilla.org, as an organization is steping on allot of feet doing this, and it is a very GOOD thing!
I only have 2 concerns;
1.- How can we prevent 'Phoenix' (the new moz browser) from going the same route as mozilla went with undecisive UI decisions? ye, I read the roadmap, but can that really hold true? While I beielve it can, who's the one to make the final decision if no sole owner of UI is set?
2.- In context to GRE, what will prevent ONE crash by GRE to ot take down all my applications that are running off of it? If I'm runing Moz browser(Phx) and Thunderbird, and Thunderbird crashes, it should not take down my browser, but if the fault is in GRE will it then?
Again, I applaud the Mozilla organization for this wonderful proposal (and hopfully implementation).
In concern to the roadmap, I think it should be made clearer, how easy it is to move you application from Mozilla based to Phoenix. Most Extensions/add-on's and applications require only a small amount of tweaks to get working (not all ofcourse).
On another subject, who's still on Netscape's pay-roll that is working on Mozilla. Are all @mozilla.org e-mail holders on Netscape's payroll. Interestingly enough, in the roadmap, their are only 2 netscape.com e-mail holders.
Is mozilla finially breaking away from netscape's hold? Are any other companies paying distrubuters to work on Mozilla/Phx?
Many might say "who cares", but I must admit that Money does pertay in a small way to the speed of development of an open source project.
Appreciate any/all feedback
"This is definitally the right decision for Mozilla. But, I hope that mozilla.org, as an organization is steping on allot of feet doing this, and it is a very GOOD thing! "
Yes, I am sure a CIO who just committed to an enterprise-wide rollout of Mozilla in support of a mission-critical app would be very happy to learn that it is a good thing his toes are being stepped on! I have a hard time seeing how Mozilla could be taken seriously in the corporate market (=80% of PC deployments) after this.
I had a hard time seeing how Mozilla could be taken seriously in the corporate market *before* this. :-)
Mpt: True, true, but I think this new path for Mozilla.org will definitally restore new faith into Mozilla the browser and platform that it never has had since the pre M9 days. True, mozilla is hard to be taken seriously in the corporate marketplace today. But I think this will change things drastically.
This show's just how mature Mozilla is becoming, and the potential of it.
I still don't get why people see this as a HUGE change! It is, and it's not. Yes it is, as the focus has shifted, but deep below, it's still gecko, it's still XUL, and moving your applications from moz over to Phx, is really not that big of a deal. Am I missing something? This is a huga change for Mozilla the Org, but for embeders, application owners, this is the next best thing! A faster, better application almost instantly! Wow!
As if CIO's like being screwed around by MSoft with each pointless bloated upgrade. They can live with 1.4 as long as they want and can even work with the community to keep 1.4.x going. Try doing that with Office 95.
Smart CIO's realize that Open Source returns some control over their destiny to them. Dumb ones won't even notice that the new Mozilla 1.5 (not mandatory, not auto-installed, and not part of some Software Assurance licensing deal) no longer ships with Chatzilla and Venkman in the Tools menu.
Last time I checked Mozilla had like 3% market share. What's the worst that's going to happen?
" Yes, I am sure a CIO who just committed to an enterprise-wide rollout of Mozilla in support of a mission-critical app would be very happy to learn that it is a good thing his toes are being stepped on"
Err somehow I don't think that's very likely. Worst case they can use the 1.4 series.
The changes that are happening are needed ones and Mozilla has little to lose. Like I said, they don't really have much marketshare to speak of, so why not fix the major problem now that are holding it back. They have a lot more to gain once they get the mainline browser seperated from the rest of the suite as opposed to the current situation where they are stuck constantly fighting this one big monster.
This reorg is needed and will finally allows Mozilla and its various components to live up to their abilities.
That's a ridiculous scenario. No CIO or corporation is going to roll out a browser that includes mail, chat, news, compose, etc.
When this whole thing gets to a 1.0 release, companies will finally be able to confidently roll out Moz-based browsers, whether to employees or companies. This focus on the browser is long overdue and incredibly refreshing.
My hunch is that no CIO or corporation is going to expend resources to roll out and support a browser when one (IE) is available as part of the existing Windows install. The only reason I can see for the average business to deploy an alternate browser on a large scale is if they want to buy into the integrated intranet communications model that NSCP Communicator was all about... i.e., the suite approach. For all the talk of browser-based insecurities, my experience is that most corporate security personnel (after consultation with the tech. department financial analyst) are content to block access to presumed-malicious sites at the proxy server and deal with whatever comes through, rather than have to justify the overall budget impact to change browsers enterprise-wide.
Companies are not rolling out chat, news and compose to (m)any of their employees. And if they are, they are using the best-in-class options that exist on each platform, not Moz.
Lotus, Microsoft and others have a juggernaut on mail servers making the mail client superfluous for the vast majority of companies.
So if a company determined that the Moz browser fit their needs, they would need to figure out how to strip out all the garbage to push it out to their staff.
The suite thing was dumb on so many levels.
> 1.- How can we prevent 'Phoenix' (the new moz browser) from going > the same route as mozilla went with undecisive UI decisions?
I agree. It seems to me that, at least from the outside, reasonably sane and simple UI modifications take forever to plow through the traditional Mozilla bureaucracy. Now that Phoenix is becoming Mozilla, I hope there will be a new Baby-Mozilla project that can act like a UI incubator in the same way Phoenix did. UI concepts need to be tested, just like everything else...
> 2.- In context to GRE, what will prevent ONE crash by GRE to ot take > down all my applications that are running off of it?
The GRE just means that multiple applications will share some common code.
Each application is isolated in its own process, so the crashing one doesn't affect any other, regardless of the code they may share (every Win32 application shares at least some code, provided in DLLs like COMCTL32.dll, COMDLG32.dll, GDI32.dll, KERNEL32.dll, etc)
Compare this with the way Netscape Communicator and Mozilla have historically done things: Mozilla isn't clever enough to share a single profile between multiple processes, so the browser, composer, and mail client must all execute within a single process, Mozilla.exe. Because of this single-process problem, a bug in Mail/News will bring down every browser window, and visa-versa.
> Are all @mozilla.org e-mail holders on Netscape's payroll.
Of the eleven mozilla.org staff members, four are paid by Netscape.
#77 Re: Wow!
Thursday April 3rd, 2003 2:37 AM
"Let me soak this in............. I remember when the Phoenix project started "as an experimental browser for mozilla technologies" and the ultimate goal was just this, but I never expected it to be so soon!"
Phoenix dealt with tensions within the Mozilla organisation by being an internal fork. A good fork being blessed as the new main line of development is a workable open-source model - e.g. when gcc was looking moribund, egcs was forked off, and became so good it was blessed as the official version of gcc.
"Is mozilla finially breaking away from netscape's hold? Are any other companies paying distrubuters to work on Mozilla/Phx?"
Chris Blizzard is paid by Red Hat, yes?
" Are any other companies paying distrubuters to work on Mozilla/Phx?"
If by this you mean "are there any developers being paid to work on Mozilla by companies other than Netscape/AOL?" then the answer is "Yes, lots, and being paid by big and famous companies too."
#14 I like my headline...
Wednesday April 2nd, 2003 2:22 PM
Ugh. I am a MCSE sysadmin type, so I am on a lot of MS centric mailing lists. Just today I got a message about the panoply of licensing options (shrink wrap vs volume) and package versions of the forthcoming Office 2003: basic standard professional professional enterprise small business edition...
... you get the point. The value of Office is diminished when you are no longer certain that my version of a suite (office, mozilla), can do all the things that your installation of said suite. Currently, if I have moz, and you have moz, we can be reasonable certain that our functionality is highly similar. It sounds like moz.org wants to get away from this, and this is a bad thing.
Having less tightly coupled applications is likely to have a higher correlation with increased bugginess with interaction between them.
Bloat is a ridiculous argument - look at the walmart lindows pcs - we all live in the age of having more cpu and ram than we know what to do with for short money. Its painful to see the bloat argument apparently torpedo the most "Mom ready" polished OSS software package into a grab bag of componentry.
I am definitely on the periphery of all moz development, as I am but an end user who has been kicking its tires since the .9something beta days. I just find it strange that a process that seems to have been releasing more features more quickly than IMHO any other phase of the 5 yr project is about to change things dramaticalls.
I hope my fears are unfounded.
Your fears seem mostly unfounded.
> Currently, if I have moz, and you have moz, we can be reasonable certain that our functionality is highly similar. It sounds like moz.org wants to get away from this, and this is a bad thing.
Not if you're exchanging documents. HTML and XHTML will work identically in a standards-compliant way between any Mozilla variations. But yes, from a support aspect it could be a problem. It sounds like your company is a candidate for a suite based on Mozilla that has the configuration you want. (The obvious answer is to take the time you waste reading MS licensing policies and spend it building your own distro with the extensions enabled that make sense for your company. :) The Mozilla project has always struggled with delivering an end-user product vs. open source project, a corporate product is yet another variation.
> Having less tightly coupled applications is likely to have a higher correlation with increased bugginess with interaction between them.
Yes, but what amazing integration is there between the current Mozilla Mail and Browser windows? And if done right separate apps will really shake out and improve the Toolkit and Runtime layers in a way that a monolithic app doesn't.
> Bloat is a ridiculous argument
Re-read the roadmap, it only mentions bloat once in the context of improving Gecko. The roadmap is an argument about project organization and focus.
> Grab bag of componentry
Re-read the roadmap. "we will likely ship with all of the popular extensions installed but disabled, so that they can be easily turned on by those who wish to use them, and uninstalled by those who don't." Sounds like a win to me, and a lot easier for Mom to deal with than the current Mozilla.
Since you are a Windows admin, your concerns are understandable. On *nix platforms the philosophy is small tools for every job, with the idea that an application that does one thing *well* is better than one that does many things halfway (kinda like people in a company....). Now mozilla is not just a *nix application, but it IS an open source application, and open source philosophy is quite different from Windows philosophy. Unlearn that MCSE -- you have been spoon-fed by dishonest men! If tight-integration between components is a necessity for good software development, then OSS, and Linux, should not exist, and my laptop here certainly should not be able to boot. Or outperform PIII machines running Windows2000.......
Honestly, Micro-centric news/info sources are heavy on pushing the One Right Way to Do Things. Start reading up on stuff from other sources, if only to avoid that spoon-feeding thing. It's like learning other languages -- very healthy for the mind.
--An un-certified, versatile Windows admin
Word and Excel are separate applications, but they are tightly integrated. Why do you think that separating Mozilla components in to separate apps will lower the integration level?
As it is, Mozilla is already hightly componentised - I can choose whether I want to install Mail, Chatzilla, etc.
I'm personally looking forward to having the components split in to their separate components. It was fundamental design flaw that they copied from Netscape Communicator. Right now, if my email/news client is busy (yes, they have some performance issues), I am unable to browse the web. Conversely, if a misbehaving plug-in crashes the browser, an email that I've just spent half an hour editting will be lost. Separating the components in to separate processes is imperative, IMHO.
#159 Re: Re: This sounds bizarre
by neva <email@example.com>
Thursday April 3rd, 2003 10:16 PM
You can choose whether you want to install Mail?
I may be on crack or something, here, but I don't remember that option ever showing up. I'm not even sure the Chatzilla option comes up anymore, come to think of it.
I dont know about crack, but definetly You have not been paying attention while installing Mozilla.
Well at least on windows - the installer offers a choice: ( ) Browser only, (*) Complete and ( ) Custom. Defaulting to "Complete". When You bother enough to choose "Custom" option, You WILL be given choice of components to install (unless You install over an existing installation in which case allready installed components will be checked and disabled, so you can not uncheck them...)
I don't mind cutting it, but what I mind are things I occasionally see in the Phoenix discussions. There seems to be a tendency to immediately notice filesize increases and immediately see them as reasons for alarm, instead of asking if there's some *reason* that the file's a little larger. You'd think that the ultimate goal was to fit it onto a floppy disk or something. (Hint: If that's what you want out of a browser, there are some rather nice textbased ones out there. They're very small and zippy.)
Cutting out things that people genuinely don't use or slimming down parts which take up more space than they should? There's a sense to that. But I have to agree--it gets taken too far. And since Mozilla's *added* so much stuff lately, it's a little weird that they want to replace 1.4 with something that's been more focused on cardio than weight training. ;)
#20 Cool in theory, but could be bad...
Wednesday April 2nd, 2003 2:50 PM
Does this mean that Phoenix will inherit all of the main Mozilla tree's delightful little prejudices?
"We won't fix that! This isn't an end-user browser!" "I'm tired of people complaining about this bug! Instead of helping to fix it, I'll mark it WONTFIX!" Oh, and my personal favorite: "Shut up, learn your way around 200 megs of code, and fix it yourself!"
Phoenix doesn't have these problems, because its stated purpose is to be an end-user browser. When the old Mozilla team moves over to Phoenix, are they going to carry their own ideas over?
#40 Re: Cool in theory, but could be bad...
Wednesday April 2nd, 2003 4:56 PM
> "Shut up, learn your way around 200 megs of code, and fix it yourself!"
I say this often.. Except it's always "Shut up; I can point you to the exact spot in the code where you would need to fix this, if you're willing to do it". I've had no takers so far (partly because when someone is willing to fix it he just asks where in the code to look instead of engaging in the whining that necessitates the above comment).
#43 Re: Re: Cool in theory, but could be bad...
Wednesday April 2nd, 2003 5:38 PM
Hmm, then perhaps I should have spoken to you the last time I volunteered to fix a bug (never got a response that time). At any rate, I'll put my money where my mouth is:
I find bug 45375 particularly annoying (as do many others, apparently), and I would like to fix it myself. I'm a reasonably experienced C/C++ coder with almost no experience with the Mozilla codebase. If you could tell me the file(s) and line(s) of the code that will need to be modified to make tooltips display without being cropped, I'll get right on fixing it.
#47 Re: Re: Re: Cool in theory, but could be bad...
Wednesday April 2nd, 2003 6:24 PM
Hmm... That's actually a neck of the woods I don't know much about, to be truthful.
I suspect that a good place to start would be nsPopupSetFrame::DoLayout (in nsPopupSetFrame.cpp). It looks like the nsPopupSetFrame::ShowPopup method demonstrates a way of getting the right popup list entry and nsPopupSetFrame::OpenPopup shows how to check whether you're dealing with a tooltip.
Once you know you're dealing with a tooltip, you can aim to change the way its laid out....
Again, my apologies for the slight vagueness, but I'm not familiar with exactly how tooltips get hooked up (otherwise I'd try to point you directly to the box implementation for them).
#65 Re: Cool in theory, but could be bad...
Wednesday April 2nd, 2003 10:34 PM
> I say this often.. Except it's always "Shut up; I can point you to the exact spot in the > code where you would need to fix this, if you're willing to do it".
So could you give me some pointers on bugs 157372 <http://bugzilla.mozilla.org/show_bug.cgi?id=157372> and 75866 <http://bugzilla.mozilla.org/show_bug.cgi?id=75866> Constant annoyances for me and many others who have seen the light and abandoned OE.
Serious Blockers of bug 164421 <http://bugzilla.mozilla.org/show_bug.cgi?id=164421> IMVHO.
#174 Re: Re: Cool in theory, but could be bad...
Friday April 4th, 2003 2:22 PM
Unfortunately, no. I'm not at all familiar with the mailnews code (and I would never tell someone to go fix it themselves in that code, as a result).
You may want to ask <firstname.lastname@example.org> for some direction... he is likely to be able to point you to the right general code area, at least.
#24 Re: ESPN standards compliant?
Wednesday April 2nd, 2003 3:19 PM
I am so happy that this is happening. I do have some questions though (copied from my blog - <http://www.chrisgonyea.com/>):
What theme UI will the new Mozilla use? Phoenix's theme is the nicest browser UI that I've used today, very pleasing on the eye and easy to figure out. I know Minotaur is going going to be based on Phoenix's theme. Will this new Mozilla use this theme as well and finally ditch the Modern/Classic themes?
Will the focus on quality, which what made Phoenix excel, still continue when it becomes Mozilla's focus? The roadmap says it will, but judging by the past I will believe it when I see it.
Will Mozilla become an end-user product as well? I seem to recall numerous bugs that are marked WONTFIX because Mozilla isn't an end-user product. Phoenix has been geared towards the end-user, so how will Mozilla keep this up or will it be the same old story?
That said, what will Netscape do? Will it continue to use the Mozilla-suite or will it change over to the separate Mozilla applications? Will it use the Phoenix theme and ditch Modern/Classic? How much will Netscape change on its own version of the new Mozilla?
How quick will the new Mozilla be developed? Does this mean Minotaur (aka Thunderbird) will get the huge kickstart it needs with more developers moving to it? Or will the process be much slower?
How soon will the GRE be ready? How soon will the GRE be used by Phoenix and Minotaur/Thunderbird?
Don't know why Phoenix autofill the title from my old post on the ESPN message. Oh well.
Try the link to my blog again: <http://www.chrisgonyea.com>
#29 Re: Re: ESPN standards compliant?
Wednesday April 2nd, 2003 3:47 PM
QUOTE - That said, what will Netscape do? - UNQUOTE - I think they'll take the seperate applications, browser, mail/news . . . etc, add the usual Netscape related end user combinations, but combine them all into a full Netscape suite. Whether they'll use seperate processes for each application within the suite or combine it as all one process, remains to be seen. Whether they'll switch to using the default Phoenix theme as their default theme, or stick to the bundled Modern/Classic combinations, again that remains to be seen. What I think Netscape should do, is both offer it's users the choice of full application suite, as it's more or less always been, and also offer the choice to download the browser, mail/news . . . etc applications seperately to each users preference, although this is unlikely.
#89 Re: Re: Re: ESPN standards compliant?
Thursday April 3rd, 2003 3:47 AM
Why would that be unlikely, Netscape 6 and 7 already let users select components to install in the custom installer, the only reason the browser had to be installed was because the browser has always been compulsory in Mozilla builds, mail/news and stuff is optional with the installer
Why are you so anxious to ditch Modern and Classic? That Qute theme that appears to be the Px default looks like WinXP cartoons and nothing like what I want a browser to look like (namely NSCP Communicator).
#114 I agree
by mlippert <email@example.com>
Thursday April 3rd, 2003 9:20 AM
I happen to really like the classic theme. I haven't seen the Phoenix theme so maybe I wouldn't mind it, but as long as themes are supported by the browser, I'd be upset to lose access to the classic theme.
#198 Re: I agree
by Ascaris <firstname.lastname@example.org>
Wednesday April 9th, 2003 4:55 PM
I like Classic too. I don't like to change once I get used to something I like, so Classic was a natural when I switched from NS4.79 to Mozilla. Back then, there was no "pictures only" option, so I modified the Classic theme to have the narrow, textless toolbars of NS4. That was my first theme. Then when Moz came out with the pics only option, I modified the new theme to have the NS4-thin toolbars with Classic. I like the classic look; to me, none of the current Phoenix themes were usable. The lack of a Classic theme for Phoenix has been one of the reasons I never gave it a "real" try. Now that it is clear that this is the way of the future for Mozilla, I got a wild hair and made a Phoenix Classic theme (yesterday, as I write this). I just uploaded it to Deskmod... the URL is:
I'm sure I will modify it a hundred times more, but I am using it now, and it works. I blatantly ripped off the prefs panel graphic from the current default "Qute" theme... the rest is from Mozilla Classic. I guess I did not author this theme so much as move it around.
#135 Re: Why ditch Modern/Classic
Thursday April 3rd, 2003 12:23 PM
Well, as much as I agree that Modern/Classic are the standards for Moz right now, I still vote for the first theme: EarlyBlue.
Cool! I will keep on using Mozilla 1.x well into the future. I won't be using Phoenix and Thunderbird as much as I would be using Mozilla.
Something about this just sounds like the perfect direction Mozilla should be going in...
Very good news guys, now we all get the sudo-pheonix smaller, lighter, faster browsers!
... is definitely to name this "Mozilla 2.0", as some already said. Just another vote on what I think is the best proposal to this change.
2.0 would imply serious back-end changes. This is all front-end work, really...
#121 I'm not so sure about that therminology
Thursday April 3rd, 2003 10:07 AM
Who says a major version increment must mean a lot of backend changes? After all, we're moving to a new toolkit, a completely new frontend for the browser (and hopefully for the mail/news client too). I think calling it 2.0 would make perfect sense.
I guess we can always get used to something new, but the classic theme is quite nice. Is it going to survive the change?
#35 David Hyatt still doing Mozilla work
Wednesday April 2nd, 2003 4:37 PM
David Hyatt moved to Apple's Safari/WebCore/KHTML, but he co-wrote the new Mozilla roadmap so I guess he's still very involved in Mozilla. (In his personal blog he talks about how mastery of two CSS engines may be affecting his life!)
#37 other major projects (like calendar)?
Wednesday April 2nd, 2003 4:43 PM
Forgive me if this is answered in the roadmap page, but how do other major projects fit into this? A good example is the Calendar. It's supposed to land into 1.4 sometime, but if they split everything from there into Phoenix and Minotaur, would it then be part of Minotaur (more logical than keeping it with Phoenix) and make Minotaur more of a PIM (almost)? Or would it be completely separate project that, through coordination by groups, works well with the other stand-alones?
#41 Re: other major projects (like calendar)?
Wednesday April 2nd, 2003 4:58 PM
"Forgive me if this is answered in the roadmap page, but how do other major projects fit into this? A good example is the Calendar."
"The other integrated components of the Mozilla application suite, Calendar, Chatzilla, and Composer (the HTML editor application), are not going away, either. We're not sure yet how they'll evolve -- whether they'll become standalone toolkit applications (and if so, based on which XUL toolkit), or popular add-ons to Phoenix (if so, they will need to use its new toolkit). But we're committed to supporting them to the fullest extent required by their owners, including providing daily and milestone builds of them for community testing and feedback."
THe company, Oeone (spelling??) had announced that the caldener is not a higher priority for Oeone right now so Oeone can focus on other projects. So, the calender devolpment and bug fixing will be at a snail pace.
#49 Actually, there's lots of calendar work being done
Wednesday April 2nd, 2003 7:44 PM
Actually, there are other developers doing a ton of work right now, so we're getting more fixes now then we did a little while ago. There are also two groups of students working on the calendar as part of their classroom activities. We should have something from them in the near future. I'm looking forward to making calendar a stand alone app! :) Mike
Calendar is a major project for the Mozilla suite. In my office environment, the lack of the functionnality was the major drawback of using Mozilla for mail instead of Outlook. This is the most missing functionnal element for me.
The current implementation does not fully solve my problem because of performance/stability problems, but over all insufficient integration with mail.
So I'm really worried if it will be possible to have the kind of full integration with both mail and browser that makes a calendar really useful after the split.
#199 Re: other major projects (like calendar)?
Tuesday July 1st, 2003 11:02 AM
Why do you think Calendar should be part of Minotaur/Thunderbird? Calendaring may *use* email, but it isn't logically *part of* email. It should stand on its own, alongside email, browsing, etc. The fact that calendaring typically gets shoved into an email client is no reason to keep doing it that way.
Sounds good. I'm not totally convinced that this is the right plan, but I am totally convinced that having a plan is much better than not having one. Since 1.0, we've been kind of drifting along with no big picture. Now we have a big picture. That is good.
This is definitely one of the big days in the Mozilla Project's history. After reading through the new roadmap, I'm pretty optimistic that we will look back on this day positively.
#42 This is great news for end users
Wednesday April 2nd, 2003 5:19 PM
I have been using Phoenix full-time on my work Windows system for more than 5 months, and it is far, far better for my purposes -- basic web browsing -- than Mozilla is. I *love* Phoenix, and I'm excited that it will become available officially for Mac OS X as well, which is what I use at home.
Regarding moving e-mail off into a separate application, I have annecdotal evidence that this will be a good thing. A while back, my mother decided to give Netscape 7 a try, to upgrade herself from using Netscape 4.x for e-mail. Her experience was awful, and she quickly headed back. But 4.x is a dead end, and she eventually moved to Outlook. I am certain no good can come of that.
So I regard Thunderbird/Minotar becoming the primary e-mail application from the Mozilla Project as a very positive development. My wife is still using Netscape 4.7 for e-mail, but now perhaps I can soon switch her to Thunderbird, instead of Outlook (which she just began using at work).
So rock on, team, this is Good Stuff!
#90 Re: This is great news for end users
Thursday April 3rd, 2003 4:43 AM
> A while back, my mother decided to give Netscape 7 a try, to upgrade herself from using Netscape 4.x for e-mail. Her experience > was awful, and she quickly headed back.
I just really wonder what was awful. Netscape 7 is a good equivalent of NS 4 for email, just a few functionnality missing, but also enhancement to compense.
The only reason for problem is the profile update, but when you switch to OE you will just loose all the profile content, so it's better to first try with a clean profile.
Ugh, so does this mean I can forget having search as part of the dropdown autocomplete? Having a second text input field is indeed a novel idea, but just typing a search term into the location bar, hitting tab, and enter was great. Is there some preference in phoenix?
Also, does this mean that all of the mozilla bugs will be migrated to phoenix? If not, what will happen to them?
"Also, does this mean that all of the mozilla bugs will be migrated to phoenix? If not, what will happen to them?"
You mean RFEs, right?
That second input field has been in <a href="<http://www.opera.com/>">Opera</a> since version 5.
#157 Minor point:
by neva <email@example.com>
Thursday April 3rd, 2003 10:02 PM
This isn't Opera.
Mozilla users are used to having the dropdown search. Phoenix does not have the dropdown search. Some of us prefer the Mozilla way, and yes, it is a bit of a worry that perhaps we'll be losing a feature we're fond of in the name of progress.
Since everyone is so euphoric, I'll play the skeptic:
Phoenix is the proper name; once again, we toss the old and bring in the new, as we did with the original Netscape code. One downside to it: People may question our commitment to the new Moz -- will we throw it out, too, when it gets too old and hoary?
Who will invest their resources in the new Moz if they question our long term commitment?
* What about hackers who worked late nights to clean up their code, only to find out it's been left behind in a product that's no longer being developed (BTW, how much XPFEMoz code will be used in ToolkitMoz? 50% 90%? How many person-hours have we lost?) Other community members contributed many hours; who will do it again?
* What about someone who convinced his boss at BigCo to build an application that depends on XPFE (someone correct me if that's unlikely)? What's their employment future?
* What about the corporate CIO, who doesn't want to use OSS because, he's worried, there's no vendor committed to the product? What will he think?
I know there are answers to these questions, but they need to be asked. Others will ask them, and we need to have good answers.
<i> Phoenix is the proper name; once again, we toss the old and bring in the new, as we did with the original Netscape code. One downside to it: People may question our commitment to the new Moz -- will we throw it out, too, when it gets too old and hoary?</i>
Probably. Note that the change is only the front end, which is a minority (but the most visible minority) of the code, so it's not like it's going to be another four years.
<i>What about hackers who worked late nights to clean up their code, only to find out it's been left behind in a product that's no longer being developed (BTW, how much XPFEMoz code will be used in ToolkitMoz? 50% 90%? How many person-hours have we lost?) Other community members contributed many hours; who will do it again? </i>
Having looked at quite a bit of the code, most is the same. Seems to me as if the majority of the reworking has been done.
I'm just barely qualified to answer those two questions and not qualified to answer the last two.
This is absolutely positively the best news I've heard in a long while. This is more important than the original Mozilla announcement because it has a real chance of turning the numbers around. Phoenix has demonstrated that Gecko is a very capable rendering engine and XUL both performs well and feels native. The new roadmap perfectly lays out these terrific plans. Great job!
#56 New Architecture = OS
by pkb351 <firstname.lastname@example.org>
Wednesday April 2nd, 2003 8:55 PM
I took a look at the new architecture for Phoenix and from my limited knowledge of OSes the structure looks a lot like the way MacOS X and UNIX is structured in componets and which makes thoses OSes speedy and efficient. Is this a fair comparison?
Does this either make the new architecture and os or very close to an os in its own right?
Mozilla is a plaform (middleware to suits), and most platforms are component based for convenience, as the problem breaks up that way and it's a logical division of labor. Mozilla isn't an OS, those do things like manage programs and hardware. The only similarity is that people make programs to run on OSs and they can also make them for Mozilla (if you restrict your definition of an OS to a platform, they're similar, but an OS is more than just a platform).
#60 I wish it were a late April Fools' joke
Wednesday April 2nd, 2003 9:09 PM
I wish this were just another bad joke. I guess I'll survive, though. I'm not too thrilled about having to live with the extra memory usage that's likely to result from having both Pheonix and Thunderbird/Minotaur running at once (and why would I ever close them? I don't shut down Mozilla now). There's never been anything compelling to make many of us switch to Pheonix, so I guess the Pheonix supporters have now found a way to strongarm us into switching.
#62 Re: I wish it were a late April Fools' joke
Wednesday April 2nd, 2003 9:43 PM
This has been discussed in the Phoenix forums to death. In theory, with the various applications sharing the code in the GRE while having their *bloat* reduce, code optimized, and increased speed, the following will happen.
Let's say Mozilla is "m", Phoenix "p", and Thunderbird "t"
p + t <= m
Basically, Phoenix and Thunderbird together should take at most the same amount of memory Mozilla takes up now. In fact it will probably take up less memory as a whole and be a whole lot faster, more stable, and one crash not bring everything down. What isn't there to like?
>> p + t <= m
That's wrong. p+m > m
Because each application will have a separate copy of GRE and supporting components in memory.
Why would each application have a seperate copy of GRE? That squarely defeats the purpose of the GRE itself.
No, there will be a single GRE, and everyone will be happy.
It may be one GRE on the hard drive, but each will have to load its own GRE into memory unless the GRE is going to stay in memory when they are closed. Whether linked dynamically or statically, both have to load the code into their own portion of memory to use it.
This still doesn't mean mozilla would be smaller, but it's not as cut and dry.
You're thinking pre-386 :>
With current computers, memory mapping means you can map the same loaded code (read-only block of memory) into the address space of two different processes. So the *code* of the GRE (a DLL, I presume, on Windows) would only need to be loaded once. However, the *data* of the GRE would be stored separately for each process.
So total memory consumption now:
GRE code + GRE data + Mozilla code + Mozilla data
Total memory consumption in the new scheme:
GRE code + GRE data + Phoenix code + Phoenix data + GRE data + TBird code + Tbird data
This is why, even though sharing the same GRE code, one instance can't crash the other one - the only shared part is the GRE code, and you physically *can't* mess up the GRE code because it is stored in a read-only memory block. [Well, ideally. I'm not sure whether the OS enforces this by default and there are ways to defeat it. :)]
Guh. It lost my line breaks. I'll try again; memory consumption in new scheme
GRE code +
Phoenix code + Phoenix data + GRE data
TBird code + TBird data + GRE data
It's possible that the GRE dll could store data for itself rather than per-process, but doing that would create the potential for fun crashes.
The dll would only be loaded once Min. or Px is loaded, right?
Isn't TBird the XUL toolkit, not the new mail client?
I see where I misread about Tbird...
#133 Re: Then...
Thursday April 3rd, 2003 12:08 PM
"Isn't TBird the XUL toolkit, not the new mail client?"
Minotaur and Thunderbird have kind of a complicated past. At various times they've been separate peojects and at other times, they've been considered to be the same thing.
The current setup is that Minotaur is the project to get Mail & Newsgroups running all by itself, without the need for the rest of Mozilla (specifically Navigator and Composer) to be installed. Thunderbird is the project to build a Minotaur-based mail client that uses the Phoenix toolkit and follows the Phoenix design philosophy (small is better and all that).
If you download a Minotaur build today, I think you're really downloading Thunderbird (but then it's not using the Phoenix toolkit yet, so maybe you're not).
It's further complicated by the fact that the name 'Thunderbird' still needs to be rubber-stamped by the lawyers (hopefully by Friday, along with the new Phoenix name).
It's something like that, anyway.
#162 Yes the DLL would only load when first accessed.
Friday April 4th, 2003 3:13 AM
and it'll unload when no longer in use.
I'm *not* really a system-level expert (and don't know anything about the mozilla code specifically) but that's about how I understand DLLs to work in general.
#80 Re: Wrong
Thursday April 3rd, 2003 2:47 AM
"Because each application will have a separate copy of GRE and supporting components in memory."
No, that's not how DLLs work. The idea is that you have a single copy of a DLL in memory, but multiple separate processes can use it. So the processes are separate (e.g. browser and mail/news can't crash each other) but they only use one lot of memory. That's why we bother with DLLs rather than all programs being a single huge binary.
#81 A mail plug-in to Mozilla/Browser
by abraham <email@example.com>
Thursday April 3rd, 2003 2:51 AM
According to the article, the mail component will have a dual exsitenc as a stand-alone application, and as a plug-in to Mozilla/Browser (formerly known as Phoenix). presumably it will share the runtime component of Phoenix when used a plug-in.
#120 Re: I wish it were a late April Fools' joke
Thursday April 3rd, 2003 10:06 AM
You're way off.
Many people (the vast majority, actually) have little say in what mail client they use so it's simply asinine to bundle it with the browser. There are no benefits from integration. IE and Outlook are *not* integrated. Safari and Mail.app are *not* integrated. And they all work fine together.
so does this mean that i won't be able to use one application (like i do now with mozilla) to do my email and browsing? will i have to use 2 programs (phoenix and thunderbird)? will there be any way to integrate them? that is the one thing i love most about mozilla...
I think I read that Thunderbird can be both standalone or installed as an extension to phoenix i.e. it can be integrated
Yes, to do two totally different and completely unrelated things, you use two programs.
#139 There will be an intregrated version
by arnoudb <firstname.lastname@example.org>
Thursday April 3rd, 2003 1:01 PM
As the roadmap CLEARLY states, had you read it all, you would have known that an intregrated version like the current Mozilla will be provided for all it's fans.
#167 You don't need to integrate them
Friday April 4th, 2003 8:02 AM
I mean, with separate programs for mail and browser, they already 'integrate' correctly (well if they are done properly). For instance you click a link in a mail program and it will load that link in your default browser. You click a mailto link in a web page and it'll load your email program, creating a message to that address.
This is the way things are supposed to work and in fact they already do (with most browsers and email programs, anyhow, including the MS stuff). What other integration do you need? I can't think of any...
And the folks like myself who have managed to do a back door install with a zip will then be starting IE. Folks no offense, but in a business that has closed the door of running exe files i.e. no installs from the net possible, however Mozilla zips with mail is away around that. If as you think well just change the default browser, that could cost some people their jobs. Plus on a shared workstation, one just doesn't go click and new default and click back again. Win 2000, Win XP Pro and .net(frame) the administrator can and does turn off Internet Options in IE.
Awesome! Best news I'v heard in a long time.
But what's in the near future for Phoenix? Long term (by July August) is moving over to Phx and Thunderbird from the Moz suite. But during that transition (moz 1.4, then 1.5 1.6) how will this be handled?
Will the announcment for Phx's new name be soon? Will a version 0.6 be released, or no release until 1.5/1.6? During the creation (in proccess now) of Moz 1.4, will worked be done on Phx? Who decides who will do this work?
I am in now way doubting Moz the Org, I'm just curious how these first few CRITICAL months are going to be carried out. Seems pretty complicated to me, but it's definitally worth it, by August we will be pissing our pants with joy!!!
Cheers to the Phx team for getting their baby and dream completed, and to the rest of the Moz folk for their awesome work to make both Phx and Moz a reality!
Thanks for the feedback!
Sorry, i think phoenix totally sucks :(
Phoenix is not even 1.0 yet and you're in the distinct minority.
#187 How do you know this?
by pkb351 <email@example.com>
Friday April 4th, 2003 8:56 PM
Have you taken a poll. Many have expressed their love for Mozilla over phoenix. Many love Phoienix. Maybe Mozilla.org should run a pool. I believe that either mozilla would come out with more votes or it would be 50/50. Just because you love Phoenix doen't me all users love it, or why does mozilla still have so many users?
Most people do not think Phoenix sucks. Sorry, dude. Those who have tried both may prefer Mozilla, but that's not what's being debated. You said Phoenix "sucks". I said you're in the minority. Please debate the argument, not your misunderstanding of it.
I am glad to see that the Phoenix will finally have official support for the Mac platform.
It is not that I have any opposition to Camino, but it will be nice for Mac users to have access to several of the XUL based add-ons that have and will be introduced for Phoenix.
I'm not getting the point of Phoenix/"XPFE browser" dichotomy in the Roadmap document. AFAIK, XPFE is essentially XUL+JS+CSS accessing binaries (or other modules) as XPCOM components via XPConnect. Is Phoenix built in a different way? And one more question: what exactly constitutes 'the Phoenix toolkit'? Of course, this is not a place to address the issue in details, but providing some link would be great.
#82 Re: Phoenix - not XPFE app?
Thursday April 3rd, 2003 2:59 AM
XPFE is actually a bunch of stuff that's been thrown together. It is A. the current toolkit for the Mozilla suite, and B. portions of the browser UI. What phoenix has done is fork some of these files, and made the lines clearer between what is part of the toolkit, and what is just the front end UI. Everything is still XUL/JS/CSS, it's just different XUL/JS/CSS in places, with a lot of the bloat removed. Phoenix uses mozilla/browser for it's front end, and mozilla/toolkit for it's toolkit. Minotaur uses mozilla/mail for it's front end, and mozilla/toolkit for it's toolkit (actually it will soon, just pretend it does now ;-). <http://www.mozilla.org/ro…-architecture-diagram.png> shows how the new world will fit together.
#84 What's gonna happen to the bugs?
Thursday April 3rd, 2003 3:19 AM
Just a thought: bugzilla has some 10000 open bug reports. Not all, but many of them will still be valid after the change. Many others will only apply to the 1.4-monolithic-branch. Who will wade throught them and decide? Many bugs (just look for very old crash bugs) are probably WFM for years, but nobody can prove it. Will they be allowed to still hang around, making bugzilla stay and make even more chaotic than it already is?
And there are cases (RFE's) which will apply to both branches. Well, ok, maybe such bugs will be split.
I think this change gives a great chance to purge bugzilla of the many bugs that just should not be there. But it also has a risk that MANY old bug reports that don't apply anymore will stay and make life difficult for everybody.
My opinion (AFAICT after one night) is that I should cut back my Mozilla/Bugzilla involvement for quite some months ("it does not make sense anymore because all until 1.4 will be thrown away and even afterwards there will be big changes for quite a time") until the dust has settled down.
#182 Re: What's gonna happen to the bugs?
Friday April 4th, 2003 6:44 PM
"My opinion (AFAICT after one night) is that I should cut back my Mozilla/Bugzilla involvement for quite some months ("it does not make sense anymore because all until 1.4 will be thrown away and even afterwards there will be big changes for quite a time") until the dust has settled down."
The only part of the product that you ever touch, use, report bugs on, triage bugs for, etc. is the front-end? If that's the case then maybe yes. But, if like most people you care about more of the product (like maybe the layout/content area, stability, performance, etc.) than the toolbars and menu structure then you should keep at it. Phoenix is 99% the same code as what makes Mozilla work. The front-end is a tiny bit of code compared to the rest.
I gues Microsoft is now laughing and writing down 3 - 0 in favor of IE on their browser board.
How can I say something like this here ? Well.. IE has nearly looked the same in alot of years... new features but it is still same old IE GUI. When Mozilla.org do this kind of big changes it also means a failure in creating a competitive browser against IE.
I guess I'm not the only one here that thinks that Mozilla today eats alot of memory and may not be the fastest browser to startup on the market. Se for example Safari, K-Meleon, Galeon ...
But I also think this was a good step to move on to the next generation of the Mozilla project but it's still a failure in one way when you think about it.
But lets forget about that and welcome Phoenix (though my project EasySearch will be shut down :( beacuse of the built in feature)
#87 Vote for bug to rename new 1.5 era to 2.0
Thursday April 3rd, 2003 3:39 AM
If you want the new era of Mozilla to be renamed 2.0 rather than 1.5 vote for the bug here:
#106 Re: Vote for bug to rename new 1.5 era to 2.0
Thursday April 3rd, 2003 7:10 AM
And exactly what is the point of this? Why do a "Netscape" and skip version numbers?
#131 I think youre misunderstanding something
Thursday April 3rd, 2003 11:41 AM
As I understand the next "big" release WIIL be version 2.0. Version 1.5, 1.6,... 1.9 will be the development-versions towards the next "big" release.
#88 Vote for bug to rename new 1.5 era to 2.0
Thursday April 3rd, 2003 3:46 AM
If you want the new era of Mozilla to be renamed 2.0 rather than 1.5 vote for the bug here:
#94 Thoughts about extensions and functionality
Thursday April 3rd, 2003 5:10 AM
I wrote this to drivers, but I'd like to share it here as a kind of request for comments:
The recent announcement of upcoming changes has disquieted quite a number of Mozilla "semi-developers" (and maybe developers and users as well) up to a point when they doubted each others contribution to the Mozilla project on IRC (#mozillazine). The main fear of this group of people seems to be that the new product will have less of the functionality they like about Mozilla. This may be functionality average users do not need and that should therefore not be in the new main product by default.
But as opposed to what some on irc.mozilla.org said the unpaid developers (even "semi-developers") _are_ important in an Open Source project - especially here where the future of funding by Netscape may not be secured for many years. And you know very well that in Open Source people work mainly on products they use themselves. So it should be important that the new product will also please developers.
The announcement seems to place the advanced functionality they like to some kind of extensions. But hopefully not extensions as on mozdev.org: those are "too far away" from Mozilla to be considered a part of it. They are just like third party addons for IE. If you really look for them, you find them, but if you meet another user with similar interest, he probably never has heard of them.
So this my proposal (or "petition", whatever) is about _mozilla.org_ hosting and developing at least some core extensions and distributing them close to the product. The vision I have is having in the default Mozilla installer also those advanced extensions listed for those interested. They may be hidden deep inside some hierarchy, as long as they are accessible. This way they would be considered part of the product and nobody could really say that his beloved Mozilla had lost what made it strong. End-users may simply click "default install" and get whatever is considered good for them. They may click "advanced" to install some more or less components (as chatzilla) - only when they go into each's details they would have the choice for some advanced extensions.
Actually this is how most big application suites' installer works: they give much more choice for those interested (e.g. in graphics suites you can select which import filters out of dozens you want to install) while still offering the ease of use for "regular" users by giving reasonable defaults. Why should Mozilla not have such a more powerful installer?
(An equivalent in zip files might be a default zip file and one with all extensions (Netscape offered "base install" and "complete install" earlier).)
And if such an installer could even be used to install single extensions later that were initially not installed - that would just be great!
But my main plea is simple: Please do not kill Mozilla functionality by moving it to mozdev.org or elsewhere, but help development and public perception of at least the most important extensions by offering a place at mozilla.org, supporting it officially and making it possible to install it with the application itself. Thanks.
#99 Re: Thoughts about extensions and functionality
by naylor83 <firstname.lastname@example.org>
Thursday April 3rd, 2003 5:59 AM
I completely agree! Make different extensions part of the standard installation so that those who wish can easily install them.
I fully support this plea. A couple of extra points - third-party addon developed outside the main project can be broken simply by unilateral API change by core developers. Such addons are also less likely to be localized, so non-English users are likely to have a mess of languages in their menus.
So, please consider a set of key extensions to be external addons in technical terms, but not in project, organizational, responsibility terms. Please deliver them as a part of releases and apply to them the same standards of quality and compatibility as to the core apps.
#123 Re: Thoughts about extensions and functionality
Thursday April 3rd, 2003 10:09 AM
This was all addressed in the posts to n.p.m.seamonkey. The "core" extensions (venkman, inspector, etc) will continue shipping with the default install, off by default, trivial to turn on, with the "turned on" state maintained across installs.
#163 Extensions in Phoenix - how they should work
Friday April 4th, 2003 3:28 AM
Sure, those 'core' extensions are going to ship, but with the new strict UI direction there are going to be many features I personally want (like the ability to use new windows instead of tabs for middle-click, or search from the main URL bar with autocomplete) which may not end up in the UI.
I don't really think the issue is whether extensions ship with the browser - who cares - but how easy they are to install. For example right now it is fairly difficult. If you go to 'Phoenix Extensions' (link from preferences), it just loads a separate web page where you have to select the extension you want and go through a slightly scary install confirm dialogue. Most of the extensions provided don't actually seem to work with the browser version in use. It's unclear whether they have installed or not. There doesn't seem to be a mechanism for extension properties... and so on.
If you look at JEdit this has a fantastic way to install plugins - all plugins are registered on the JEdit community site, and from within the program you can just go to 'install plugins' and it gives you a categorisd (tree) list right there in the dialog. (I think the list is filtered by required version etc. as well.) You can click on items and get a description. Then click install and it is installed for you. (I think you can also have it automatically update all your installed stuff to newer versions.) If you want to uninstall you can do that too, right there in the dialog. And properties for extensions automatically are added right to the preferences dialogue.
Now I can see that extensions in Phoenix aren't finished yet, the program is only 0.5, and hopefully many of these features will be incorporated. But I really think now that Phoenix is becoming the official mozilla.org browser, it's VERY important to have official (mozilla.org hosted) plugin registry that maintains a categorised list of available plugins, their versions, and an absolutely definitive indicator of which browser versions they work with. Ideally this would also provide a nicer (software-UI-style) interface right in the browser preferences for installing them, though that could be done in HTML within the window obviously, and for doing things like automatically updating versions.
So you'd go to the dialogue, check under the 'User interface' category, and find the extension you want in the list right there. There's a link to bring up more information if you want it, or one-click install. The feature is then available in the list, with preferences and documentation directly accessible. (Maybe the initial one-page documentation should also pop up after you install.)
Next time you go to preferences/extensions, you click 'Check for extension update' and it goes off to mozilla.org and looks for you. Two of your extensions have newer versions available, both of which still work with your current browser version. So this information is passed on and the user just clicks 'ok' to update both extensions.
That's (IMO) how it SHOULD work. Will it?
* Host an official extension registry
* Ensure that only extensions guaranteed to work in current browser version are shown
* Ensure that extensions have a simple mechanism for preferences *and* documentation/basic instructions
* Use Web services rather than just random separate-window HTML pages to provide extension lists, data (so that it can easily do things like a software UI, checking whether plugin works in browser version, etc.)
#168 Re: Extensions in Phoenix - how they should work
by JBassford <email@example.com>
Friday April 4th, 2003 10:44 AM
> * Ensure that only extensions guaranteed to work in current browser version are shown
The converse would be (and should be - I agree with your post) that the installer for Mozilla would first check to see if you're currently running with an extension that is known NOT to work with the version you're about to download. If there's a known incompatibility, it would let you know, offering you the choice of aborting the install and removing the extension, or continuing anyway.
How about a compromise? We could ship the browser in a package much like Phoenix is today, but with one difference. Under each pref panel, there would a button that says "Get Extensions." If a user clicks this button, he is taken to a web page that lists extensions that he can click on. If he clicks on one, it will automatically be downloaded and installed, just like a XPI component. That way the browser as shipped is as light as possible, yet installing extensions is easy.
How does that sound?
#97 Extend Minotaur with Calendar, create Outlook alt.
Thursday April 3rd, 2003 5:25 AM
Just as the roadmap talks about embedding Minotaur into Phoenix, the way forward for the calendar could be as an embedded extension for Minotaur.
Some people like a standalone mail/news client that isn't your jack-of-all-trades Outlook/Evolution replacement. That's going to be Minotaur.
But Minotaur could also be an Outlook replacement for those who are looking for that sort of solution. Allow the calendar to be installed as an extension (like Phoenix's extensions) and you've got three of the main features of a PIM (mail, address book, calendar). Develop some sort of stickynote-style scratchpad extension and you've mostly got the whole thing.
Evolution at the moment is only available for Linux and friends, and it seems as if there are no plans for a Windows port any time soon. This would provide a lever for those on Windows to abandon MS Office entirely. I mean, OpenOffice.org [openoffice.org] replaces much of the rest of MS Office bar Outlook; a Minotaur that can be extended to be that Outlook replacement would finish the job.
Not to mention having a further competitor to Evolution on Unix and Linux, particularly once Kontact gets going.
Going the extension route makes far more sense than adding the Calendar to the monolithic Mozilla suite, slowing everybody down.
And anyway, does a stand-alone calendar really make sense? A stand-alone Composer perhaps. But a calendar naturally fits into a PIM environment - surely this is the way forward?
Can't agree more, when I read of stand alone calendar, my immediate thought was "That's weird", there are tons of stand alone calendards for both Linux and Windows (and probably Macs), but they are useless if they are not in the suite with the rest of the PIM solutions.
I believe that if calendar is used, then it should be part of Minotaur not Phoenix (Mozilla), and it should be tightly integrated not just a hanging secondary program. I think that calendar should be part of what will be Mozilla mail aplet that sits in tray in windows/kde and checks your POP3/IMAP boxes and at the same time notifies of scheduled events. Any other solution is useless imho, I need to be notified of events even if I don't have a full program running, the same about e-mails. I want to be able to share my calendar via e-mail. So recepient can add my events to his/her calendar...
I think that OutlookXP is near perfection suite, however some 9 month ago I've moved to Mozilla mail, because I liked some of the features. However, if tomorrow OOo will release their Outlook clone (which they unfortunately don't have any plans to do) I would instantly move into it, since for mail/calendar/address book I need integrated solution.
#141 Re: Extend Minotaur with Calendar, create Outlook alt.
Thursday April 3rd, 2003 2:27 PM
I couldn't agree more. Calendar should be an extension, albeit a very large extension, of Minotaur.
Speaking of PIM features, how is the Palm Sync conduit development going? I first tried the conduit when it first came out and it didn't work with my Hotsync application. I haven't posted a bug on Bugzilla because, frankly, I was a bit intimidated by all the fields to fill out and from the many complaints by the hardcore Mozilla guys of duplicate bugs.
As it stands now, all my applications are extremely fragmented. I use Mozilla for browsing and composing html. I use netscape 4.8 for mail and address bood (since I can hotsync with that), and Palm Desktop 3.x for my calendar since NS4.8 no longer has a calendar.
Anyways, I can't wait for Phoenix and Minotaur to be the main applications. After that, when the calendar and palm sync conduits get polished up, I'll be running with all pistons on Mozilla, or whatever the project will be called.
Architecturally I think this is absolutely definitely the right thing to do, with no question whatsoever. The facility to allow extensions (particularly if these can be extensions into Gecko - kind of a new browser plugin format but at a more powerful/easy to manage level) but keep the basic install simple is exactly what's needed.
From a user interface point of view though, rather than technically, I kind of think Phoenix sucks compared to Mozilla :(
(And that is assuming you use Mozilla just as a browser.)
My hope is that with main development effort on Phoenix, not Mozilla, it will improve quickly. I'd like to see them incorporating a professionally done version of GreyModern, or else some other non-suck scheme (orbit is not so bad) with large buttons by default. There are a lot of Phoenix themes but most of them are pretty poor and as usual, themes don't always keep up with browser features...
I suppose that's my other concern with the 'stronger UI lead' aspect of this - so far I think the 'stronger UI lead' in Phoenix hasn't really made a better UI. There are important UI features that Mozilla is missing, like configurable toolbars, so I definitely see the technical improvements, but the interface itself is still a bit of a mess by comparison (IMO). As far as interface is concerned, Mozilla suite 'bloat' has no real effect on me: five buttons wasting room in the status bar, sure, but who cares. I don't *use* the ugly 'new' menu, I press ctrl-n. :)
And I hope there are extensions at the least that let those of us who don't use tabs consider Phoenix, including middle-click to open new window etc... you don't seem to be able to do that at present (within the GUI).
#101 Happy... but not? If that's possible?
by neva <firstname.lastname@example.org>
Thursday April 3rd, 2003 6:24 AM
I like the idea of splitting the browser and mail client--and I definitely like that Phoenix is a bit more user-centric than Mozilla's always been. But there are a few things that bother me about this.
First of all, Mozilla-the-browser and Phoenix aren't identical at the moment in terms of feature set. Some things are done differently, sometimes in a largish way. (The dropdown searching from the location bar was mentioned in a previous post, and is something I use a *lot*.) Phoenix gaining the additional development power will solve some problems, but it doesn't exactly deal with what they're going to do about places where the two programs have already taken different paths.
Second, what're they going to call it? Will there be, in essence, no more 'Mozilla'? Or are Phoenix and going Thunderbird/Minotaur/whatever to be called Mozilla-Browser and Mozilla-Mail? Or what? That's not terribly clear, and among other things, it's kinda hard to evangelize to friends and family and coworkers and the like when you don't even know what to tell them they ought to use.
Third, does anybody know what Netscape and the like are going to do about this? Are we going to see a Netscape Browser and Netscape Mail done separately, eventually? Will they continue to merge many things into one program?
And fourth, and finally... what about the things *other* than Phoenix and Minotaur/Thunderbird/whatever? What about Calendar? What about Composer? What about Chatzilla? I don't necessarily use these things, but some people must, and it doesn't seem immediately clear where they'll fit into the grand scheme of things. More separate programs? This stops seeming like such a good idea when you start thinking about using all of these things and having to install and run them all separately. How well are they all going to integrate when they all run separately?
So... well. I think this has the potential to do good things, but I'm really unsure at the moment of what to expect. I really can't see why the existing model is so bad and must change, but I hope that changing it won't leave those of us relatively happy with the way things work in the dust.
#134 Re: Happy... but not? If that's possible?
Thursday April 3rd, 2003 12:17 PM
"Happy... but not? If that's possible?"
The feeling you're describing is ambivalence. :-)
Smartass. (Am I allowed to say that here? I'm saying it anyway. So there!)
#172 Why flame uncertainty over phoenix ?
Friday April 4th, 2003 1:08 PM
While not sharing neva's vocabulary it is understandable in the in his original post he was mearly stating his thoughts over this change.
Have some of you really read the answers, over 90% of those posts of uncertainty or of saying plain out, 'no thanks' or 'I don't agree' are being flamed, ridiculd.
Why is this? Is this a forum or a place of worship where the none worshipers are run out of town on a rail?
#176 I don't think it was a flame?
by neva <email@example.com>
Friday April 4th, 2003 2:48 PM
For the record, also, I'm a 'she'.
And I think the response was light-hearted in nature, or that's how *I* read it, anyway.
#177 Re: I don't think it was a flame?
Friday April 4th, 2003 3:40 PM
"And I think the response was light-hearted in nature, or that's how *I* read it, anyway."
That's how it was meant to be.
#188 Why flame uncertainty over phoenix ?
Saturday April 5th, 2003 12:23 AM
Okay, point noted.
@ neva sorry for the macho automatic he instead of trying to write an unsex 3rd person also for choosing your thread to express what I see in this topic.
@ AlexBishop I chose to respond to your post, because of your position at Mozillazine and thought that perhaps it would be read by more folks here. Point is, and this was in my post, this is a change for some of us end users that will take awhile to digest. For myself I was very surprised when I came to the forum and read about it. I have been on the back side of the moon for awhile and had no idea that this was coming. (back side of the moon= teaching myself to make SVCD and DVD out of ten years of video footage i.e. 6 to 12 hours of rendering time) I started with Mozilla 5, remember back when one had to write in their own pop3s into the profile.js? Anyway, since seeing this post I've unzipped a Phoenix for the very first time and tried to import my Mozzy bookmarks, doesn't work and thought gee, they are telling to start all over again. Well, in closing; I like Mozilla, it starts faster than I can take a sip of coffee on my machine(with out preload) and every thing is now finally there under one hat including my favorite, as you might guess, SVG.
#104 When does Phoenix get Talkback?!
Thursday April 3rd, 2003 6:54 AM
Phoenix crashes rarely. It does crash, though.
So when will Talkback be available for it?
#124 Re: When does Phoenix get Talkback?!
Thursday April 3rd, 2003 10:10 AM
When it's built by Netscape rather than by Asa in his spare time, I would assume.
#183 Re: Re: When does Phoenix get Talkback?!
Friday April 4th, 2003 6:53 PM
Actually, it's bryner, not me. We've had talkback in the past and we'll have it again soon, I think. There was a problem with space on the talkback servers and they booted us out but that should change as Phoenix takes a more front and center position.
Configuration and state, that is. I'm not so much concerned about the state of the UI and the components which present themselves to users, as that of the bits which tell those components how to behave.
Things which ought to be grouped together are scattered all over, and often the poor sysadmin. can find no hints as to where to look for things which, in an institutional setting, ought to be easy to find and to tweak. (Take a simple thing like the page which shows up the first time you use the browser. We've got a fleet of public stations with a potential user base of 6 *million* people, and no way are we going to deal with storage for six million profiles. So I've rigged the stations to delete profiles at logoff. This means that, here, *every* time you use Mozilla is the first time you used Mozilla. Since we use the browser as THE user interface to our services, we want *our* page to show up the first time. It took *days* of research to find out where this was buried, and still longer to figure out how to defeat it. I did the same thing to IE in a couple of hours, and IE's configuration mechanisms are not exactly advertized either.)
Also, cross-platform has been over-extended into the welter of configuration files. The result is a configuration system which is equally frustrating on all platforms. It wouldn't be that hard to wrap platform-native configuration mechanisms in common functions, so that native mass-configuration tools can be used in institutional settings. (Like, ADS Group Policies for our thundering herd of, pardon the expression, Windows 2000 workstations.) Yeah, I would write it myself, if I hadn't come away from every encounter with the code wondering, "what language *is* this, *really*?")
Mozilla is great, I use it myself all the time, but it's become a nightmare for sites which need mass-deployment, mass-setup. and intimate control of the product's behavior by IS/IT staff rather than individuals. It's really hard to use it as a component of *my* designs.
The picture (roadmap/branching-2003-02-20.png) on the roadmap page does not seem to match what they are describing. Shouldn't the 1.4 branch continue off into the right side of the screen and the 1.0 branch get stopped at that point if 1.4 is going to replace 1.0 as the "solid-as-a-rock" version?
A picture is worth a thousand words, right?
#184 Re: Roadmap picture...
Friday April 4th, 2003 6:54 PM
I'm workin' on it.
I read through about everything here and not once did I see this. You can't use the name 'Phoenix' Not my idea and I'm sure that this isn't new, however have I missed something? Is the name Mozilla dead or is it that one will use 'Phoenix' but just call it Mozilla, I'm confused.
The below is a paste from: The 'Phoenix' project page <http://www.mozilla.org/projects/phoenix/>
Phoenix needs to be renamed
The Phoenix project will soon be renamed because of legal issues. After many months and several hundred suggestions, Phoenix's new name has been chosen (and it's not Phallus!). It will be revealed shortly, after some final legal checks have been made.
Okay, just downloaded this bird and quess what? Do I really want to start over again down the buggy road. He**, it can't even import the book marks from my Mozzy Profile, Yes, I made a new profile for this puppy and well -- Guess someone will make a PLUGIN for importing bookmarks.
Speaking of plugin, think I'll toss in Adobe's SVG dill and see if this bird can cook.
#125 Import bookmarks = easy to do
Thursday April 3rd, 2003 10:18 AM
Go to your Mozilla profile directory, copy the profile, go to your Phoenix directory, paste the file. Import Bookmarks = Done.
That said, I am sure Phoenix and it's future versions will incorporate a way to migrate stuff like bookmarks over to it. Don't you worry.
I have two comments to make
1. I can't BELIEVE that we're starting over again! Didn't mozilla already re-design and "componentize" the architecture - 5 YEARS ago? How many thousands of man-hours are going to be thrown away this time?
2. This announcement is going to immediately put a halt to a LOT of development effort. Who wants to work on a dead end project? I know that I'm not working on my project anymore. It's really demoralizing to have the rug pulled out from under you without any warning. And what about 1.4? Who's going to care about finishing that up? Maybe they should have waited until after 1.4 to make this anouncement.
#152 It isn't as drastic as you make it out to be.
Thursday April 3rd, 2003 7:21 PM
It isn't going to take years like it did last time. Phoenix is already to the point that you could almost call it a 1.0 browser and that took only 8 months or so. It was all based on the current Mozilla code, with mostly improvements to the UI, work to speed it up, and removing non-important files. No thousands of man-hours were thrown away, I think they were well invested.
Development efforts haven't halted with Phoenix, in fact they have increased. Most extensions now are usable in Phoenix and only minor changes from what I understand are needed in order to get anything that is based on Mozilla to work with Phoenix. There is probably as many themes for Phoenix (if not more) compared to Mozilla.
Having 1.4 done and ready prepares those who will base their software off of it. They can get a stable product out and then concentrate on helping Mozilla work on this new direction. It has been way too long between the 1.0 stable release and the 1.4 stable release. This allows the latest Mozilla features to be used in products like Netscape while the new applications are being worked on.
There is PLENTY of warning. Think about it, we are still at 1.4 alpha. There is still the beta and then the stable release to go. That is a good amount of time to prepare for the transition.
Also I should point out that Phoenix for a good portion of those 8 months didn't have much work done on it since it was a side-project of a few individuals. If Mozilla organizes itself correctly with this changeover, the increase in manpower and the right focus will greatly increase the speed that this project will be developed.
#156 Re: Please God, NO!
Thursday April 3rd, 2003 8:41 PM
"We" are not doing anything because you clearly aren't involved in the development of Mozilla or you wouldn't have made that ridiculous post.
Software *needs* new architecture. Software grows, changes, and then you discover the old architecture (while great then) isn't great now. Stuff gets *better*. That's good news, not bad.
Making a tweak to some parts of the architecture after 5 years (it is actually more recent than that, but regardless) is hardly surprising at all.
Why do people who obviously know nothing about software development continue to post about software development issues? :)
I must say, despite Blake's and leafdigital's responses, permanentE got an answer to a very good question: What are the consequences for the hours that contributed so far? How much of the product of that labor is retained in the new Moz? And what are the political ramifications of that?
These 'developer issues' affect everyone, and the Mozilla community is much bigger than just developers. I've put in many hours, none of it development work.
Thanks to cgonyea for a helpful answer. One question remains: How many person-hours of work will be lost? 5%? 25%? Obviously, only a rough estimate is possible.
#185 Re: Re: Please God, NO!
Friday April 4th, 2003 7:42 PM
"One question remains: How many person-hours of work will be lost? 5%? 25%? Obviously, only a rough estimate is possible."
The source is there. You can find an answer for yourself. Count the lines of code that create front-end elements are unique to Mozilla's front-end (that don't also exist in Phoenix). Now count the number of lines of code for the rest of the Mozilla application (all of gecko, necko, the toolkit, nspr, nss, editor, jsengine, oji, printing, xpinstall, xpcom, etc.) Make some estimate about how much time it takes to write and debug front-end code compared to back-end code and then do the math. My guess is that the unique front-end code for Mozilla is less than 5% of the total codebase and I'd also guess (I could be wildly off here because I do neither) that writing and debugging XUL and JS is faster and easier than C or C++.
You also have to look at how much of that old Mozilla code provided the basis for the new Phoenix stuff. The Phoenix options window, for example, is different than Mozilla's preferences window, but I'll bet if you look at the code you'll see that some of the new stuff is based on the Mozilla preferences XUL even if the window does look radically different. So was that Mozilla work wasted work? I say no. Not only did it provide useful access to the feature for many years, but it also served as the base for the advancements that Phoenix made. So maybe a better way to look at this is to look specifically at the time that was put in to just the particulars that aren't and won't be in Phoenix at all, and are not likely to be converted into standalone apps or extensions excluding any of the underlying toolkit or even some of the implementations that have been modified or otherwise reused, repurposed or extended to create the new Phoenix stuff. You'd probably also want to exclude some of the time put into even those particulars because they provided a valuable testing implementation that helped us to stabilize and improve the underlying infrastructure.
It's a tricky question. How many hours did it take to name the menuitem "Preferences" and place it on the Edit menu. Is that work lost now that the menuitem is called "Options" and was moved to the Tools menu? And how different is that from the hours that were put into making a table lay out one way, realizing that it wasn't ideal for the standard or the real-world web and then making it lay out some other way?
You should also probably factor in the time saved for Mozilla by the handful of very useful features and improved functionality that were developed for Phoenix and later incorporated in Mozilla at much less cost (everything from the re-write of bookmarks, to quicksearch, toolbar overflow, etc.)
Is it "lost" if it gets turned into an extension and moved to mozdev.org?
Is it "lost" if it the original author thinks it was buggy and created a less buggy replacement?
If some of your goals are higher quality/stability, increased performance, and reduced size then is the net effect of making massive improvements toward those goals by whacking a feature still considered a loss?
I'm not sure what the final answer is. I personally believe that we're gaining more than we're losing in this transition. That's why I support it. There's no doubt that some very talented individuals (several of them, blake, ben, hyatt, hewitt, are the folks that created Phoenix) put a lot of time and effort into the old Mozilla front-end. Whether or not it's fair to call that lost work and if it is, then how much lost, is not as easy as your question suggested. Notice that I said above that you could find _an_ answer for yourself. I suspect there are many different answers to this question depending on how you look at it.
Thanks for framing the answer. I'm not attacking the proposed roadmap, I was asking because it's important to look at costs and I hadn't seen it discussed in any detail. Every great decision still has costs, which should be examined.
Asa wrote, "I suspect there are many different answers to this question depending on how you look at it."
I agree; it requires experience and judgement to frame a range of answers, which requires someone with a much better understanding of Mozilla the I have.
Asa covered the browser front end, obviously the most critical piece. What about the rest?: * The toolkits * Mail / Thuderbird * Composer, etc -- how much does it take to convert them to extensions?
There's obviously a big upside, but I'm just trying to figure out how much it will cost.
How about trademark infringement in case of Minotaur? There is a company Minotaur Technologies LLC - <http://www.minotaur.com>
They're a shop, Minotaur is a mail client. These are completely different categories in trademark law.
Two companies/products can have the same name as long as they deal with different categories of product (eg if one is a metal working factory, then you can have a perfume with the same name or a television, or a shop or even an internet mail client).
It seems that there will be two different browsers for the OS X - Camino and Phoenix. Is this really necessary? I mean it's not like AOL has an unlimited development funds for all this.
I suspect one will "win" out in short order. Hard to say which with the increased Phoenix support vs. the superiority of Camino's native interface. Phoenix is probably the way to go if they can get the interface up to par both in performance and aesthetics.
What does AOL have to do with this? Phoenix is, at the moment, developed in large part by people who don't work for AOL....
#193 My guess is Phoenix will win!
by pkb351 <firstname.lastname@example.org>
Sunday April 6th, 2003 6:46 PM
With David Hyatt (paid I believe by Apple to work on Phoenix though I could be wrong) Phoenix will take over from Camino unless volunteers can be found to take over Camino. I hope I am correct since the Camino browser is much too bare bones a browser for my needs!
#195 Re: My guess is Phoenix will win!
Monday April 7th, 2003 6:02 AM
AFAIK, Hyatt is only paid by Apple to work on Safari. Why would they also pay him to work on Phoenix?
Anyway, I disagree with the idea that there is a competition between Camino and Phoenix where only one will win out over the other. Both browsers have very viable futures which serve different purposes.
Mozilla desperately needs to consolidate efforts so that it can put out at least a single browser that competes effectively and gathers momentum. If Phoenix can get performance into the ball-park of a native-interface browser, it should appeal sufficiently to Camino users such that it "wins".
The Phoenix based browser is necessary so that cross platform XUL based features and XUL web apps will continue to be available on the Mac platform.
Camino is necessary in order to provide Mac users with the highest performance web browser that truly looks and acts like a Mac application.