Slashdot Log In
Report From The Mozilla Developer Meeting
from the not-a-dinosaur-a-*regular*-saur dept.
About 50 people packed into the Sputnik conference room at Netscape yesterday. Around 12:30 Mike Shaver and Alphanumerica's David Boswell kicked off the meeting. "Hopefully, this'll be the first in a series," Boswell announced. "Annually is ridiculous," he told me later. "I'd like to see it happen every three or four months ..." The two sounded the theme that Mozilla development was happening -- whether people were aware of it or not.
At one point, Dave Sim from the O'Reilly Network said "I've learned more in the last hour and a half than I have in the last two years." Mike said that was the problem: their story that wasn't getting out. "What is the story?" Sim countered. "What is the big picture?" Shaver said the real problem is there are lots of stories. Yes, there's users that want to use Mozilla as a full-blown application -- but there's also people who want to develop applications for the Mozilla platform, with others focussing on interoperability. "The platform story is one of the best things about what Mozilla does."
Alphanumerica's David Boswell agrees. "We see Mozilla as an application virtual machine that will allow us to write applications." Because the application can run on any system with a Mozilla browser, developers reach systems running Windows, the Mac OS, Linux, OS/2, and even Amiga and BeOs systems or set-top boxes. Pete Collins pointed out later that "Mozilla is 95% cross-platform code." He described the Mozilla platform as "write-once, run-anywhere -- done correctly."
That could be a huge draw. Earlier in the meeting someone suggested a "People who are doing stuff with Mozilla" page. "We had one long ago," Mike Shaver joked. "It listed NeoPlanet." But now, according to Pete Collins, there's been a spreading interest in Mozilla. "Since November, December, it's really starting to pick up momentum ... Alot of validations are happening because things are being done externally." Cameron Price had flown down from Real Networks in Seattle to attend the conference. Identifying himself as "just a grunt software developer," he pointed out what everyone was saying: it's not just a browser, it's a set of tools. During the group discussion, one developer even said "I'd like to see Mozilla come out and not have any browser with it."
A quick survey of the room revealed some impressive projects. Aaron Leventhal, who flew in from Wisconsin, is working on wearable computing and voice-browsing for the blind. A generalized user interface would allow seamless transitions between devices with Mozilla. Another developer wants to make his own R&D distribution of Linux using Mozilla's XML parser. ("Everyone writes specialty XML parsers," Cameron Price told me later.) By the end of the day the developer said he'd gotten answers to his Linux implementation questions. But more importantly, he'd gotten a sense of where the other developers were going. "The scope of what people have planned is mind-boggling. I feel so much smaller."
Mitchell Baker, who identified herself as Mozilla's "chief lizard wrangler," said that as a result of the meeting, "We learned how many people are writing applications using Mozilla." Pete Collins said the turn-out was a positive sign -- "Overall, just a good vibe" -- and so did David Boswell. ("Very validating. A room full of 80 external developers ...") "I don't think we're gonna have a really simple platform in the year 2000," Mike Shaver warned the audience. But the release of a preview version of Netscape 6 had already generated some interesting issues for the group discussion.
The first question in the developer group discussion came from Asa Dotzler, an independent QA tester from Austin, Texas. ("I test the tip," Dotzler said at Thursday's Mozilla party.) He asked a deceptively simple question about how they're defining "skin" and "package," and Dave Hyatt conceded the definitions they were using internally clash with public definitions. The problem is that what people think of as "skins" are more like Mozilla applications or packages -- and that needs to be clear, for security reasons. (A generalized system for ensuring security was suggested -- maybe giving skins directory-specific access. Someone cited the way this is handled in Java 1.2, and Mike Shaver said "maybe that's a model we can copy" if necessary.)
The group discussion continued for nearly two hours, and the other big issue was bug reporting. Dotzler gave an exaggerated example of an off-target bug report: "This Net2Phone button on my toolbar isn't working." What do you do with reports of non-Mozilla bugs? "You shouldn't even take bug reports on alternate skins," one developer suggested. Or should you? ("That's a slippery slope. Let's see how big a problem it is ...") Shaver said it doesn't seem unreasonable that people are going to want to report bugs about Aphrodite. "It may not be our fault, but it may be our problem ... We can create a tag for that easily. I think that's the way to do that and not panic too much."
The bigger concern is how the handling of non-Mozilla bugs will scale.
"As long as the bug database holds up."
"It should be the author's responsibility."
Someone even suggested they "take a lesson from Slashdot and have some volunteers for triaging." Everyone began talking at once. "Now we're going," Mike joked.
He started by saying "I don't think we want to follow the Linux kernel module of bug tracking." He seemed to be leaning towards the rule of thumb that "If it's in the source tree, it should probably be on Bugzilla," and later suggested that maybe "Anything that goes into the tree should have a module owner and a QA contact." Across the room, someone pointed out the implicit vindication in worries over having too many bug reports. "I think this is a marvelous problem to have. I look forward to having this problem. This means we're successful."
After the group discussion, the developers broke up into three smaller, intense groups discussing skins, bugs, and applications. Mozilla developers are already working on skin-switching for beta 1. (Several skins could be active at once -- for the browser, the newsreader ...) Alphanumerica's Cameron Barrett, leading the skin group, talked about how he built the Sullivan skin, with some help from Pete and David building on Aphrodite (which started out as an open source skin). He said he started making the Sullivan skin in early March -- with no Mozilla experience at all. After a week to get up to speed, he completed the design in a week (mostly by doing mock-ups in Photoshop), with another week and a half for coding. Total development time: four weeks. He talked about the challenges of designing a GUI for different platforms. (Predictibly, there's lots of issues with the Mac OS. "You could emulate your own windows in the Mac, but it wouldn't be very Mac-like. You have to give them a software that's going to behave the way they expect ...")
Barrett predicts hundreds if not thousands of skins once the skin-switching is incorporated into Mozilla. But after the talk, he said skins also serve an educational function. "Our main message was to get people to understand that it's so extensible." So what happens now? "I think people are gonna experiment."
At the applications meeting participants discussed packaging and install questions, API issues, sound, and Unix plug-ins with Mike Shaver. Someone asked about installing Mozilla on Unix networks and maybe even in Linux distributions, and another developer suggested making an easy-to-digest package out of Javascript. And yes, they're still recruiting people for Mozilla hacking. (Mike Shaver joked that "If all the people who were at the party last night had spent those three hours fixing bugs ...")
The problem with developing applications for Mozilla is that Mozilla is a moving target -- the platform is evolving while people are developing. One developer suggested the solution might be writing apps for a specific build -- M14, say -- and then upgrading as necessary. (And there was some discussion about the term "beta" vs. "stable branch points" or "snapshots in time with a name" ...)
Later R. Saravanan showed the applications group XMLterm -- an Xterm-like interface written using the Mozilla component libraries. On a Dell laptop, the interface was running Emacs -- including cursors -- and even Towers of Hanoi. ("A new regression test," someone joked after a few moments of stunned silence.) Saravanan said it took him 10 months, working part time ("It's not my job!") -- and that it had never crashed.
Mitchell Baker was part of the bug group, and says they discussed "the question of building community and educating people on how to produce better-quality bug [reports]."
The other impressive application was a remote script editor -- and Alphanumerica's next project is crash-recovery functionality -- saving state information on browser windows.
Boswell said the turnout was higher than he expected, and was already planning the next developer meeting. "It would make sense to have the next one in New York. Or at least not in San Francisco ..." Meanwhile, O'Reilly's Open Source conference in July will also have a Mozilla track.
Note: Readers interested in grabbing some Mozilla and Netscape 6 compatible skins should see the choices on offer at alphanumerica and mozillazine.
LIZARD, not Wizard! (Score:3)
It's "chief LIZARD wrangler", come on, even I know that. Project Gecko, Mozilla's a big lizard -- come on, why would she be wrangling wizards? Their pelts aren't even good for much of anything....
Just think what Perl could do... (Score:5)
Unfortunately, Javascript may not be the ideal language for writing these cross-platform applications. The thought that's floating around in my mind right now is adding Perl to the mix. It's already impressively cross-platform, and an extremely powerful programming language. Just imagine what you could do with Mozilla's platform coupled with an embedded Perl interpreter and Perl language bindings (e.g. for XUL) as good as (or better than) Javascript's bindings...
Re:The Difference between Mozilla and Netscape? (Score:4)
Things I Wanna Do... (Score:5)
2) Chop out Email, News. I want a web browser. I already have an MUA and a newsreader.
3) Single-menubar-button toggling of Java/Javascript, and image-autoloading. I usually want 'em all off all the time. Sometimes I have to turn 'em on, and I don't want it buried under three levels of menus like in Nutscrape 4.xx.
Too ambitious? (Score:4)
I admit that I haven't been following the Mozilla story as closely I as I probably should be over the last few months, but now I see the reason that there isn't a fully functional browser release. Since when has the Mozilla project been about a platform? It sounds like Mozilla is trying to be all things to all people, instead of just concentrating on one thing, and doing it well. While I appreciate that a platform is of more use overall than a single application, there are some of us that have been waiting patiently for the browser that Mozilla promised for a long time.
It sounds like the project has become a little too ambitious too quickly. I would love to see all these various projects come to fruition, but it sounds like all the projects are being delayed up by all the others.
This is probably too simplistic a view, of course; I don't mean this as flamebait, and I'm sure I will be corrected. Am I the only one who is frustrated from two years of waiting for Mozilla?
darren
Cthulhu for President! [cthulhu.org]
Re:Just think what Perl could do... (Score:3)
I agree -- JavaScript is a broken language that really only makes sense in the context of a web page; using it for scripting of anything else is really pushing it. I've always thought that Microsoft's use of JavaScript in the Windows Scripting Host was pretty dumb (it's not a system scripting language, people! It's just not!) However, embedding Perl into Mozilla would add 1 Mb to the size of the runtime... is that what we want? Although it does sounds like a groovy idea. There would be no limit to what you could make Mozilla do.
Does/will Mozilla allow for things such as an embedded interpreter be loaded dynamically, or will it always load everything on startup?
darren
Cthulhu for President! [cthulhu.org]
Re:The Difference between Mozilla and Netscape? (Score:4)
Imagine if Mandrake suddenly decided to stop using RedHat. Suddenly they would need to do all the work RedHat had been doing for them. Why duplicate effort?
Bad Mojo
Embedding Perl in Mozilla (Score:3)
I know that Mozilla is very modular, but I'm not sufficiently familiar with the dynamic loading capabilities (if any) to answer your last question. I don't know if Perl glue would need to be in an XPCOM module (which is probably best) or whether it could be a "plugin" that end-users install (which might be XPCOM; I don't know), but I'm sure it must be possible to embed Perl without re-architecting Mozilla again.
I guess this is a project I could try to work on sometime (if nobody else is already doing it), although there's a lot of code I'd have to familiarize myself with before I could even begin...
Re:PerlScript is server-side... (Score:3)
Re:Why Perl? (Score:3)
2) Perl is powerful.
3) If people who wrote web pages for a living knew perl, there would be better web pages.
4) Items 1-3 are the posters opinions.
Bad Mojo
Why not Perl? (Score:4)
People who write web pages for a living often have to deal with Perl already for server-side CGI scripts, unless they're an ASP or PHP shop. Perl may have a lot of features that are hard to learn, but you can start small and use just the features you do understand. Strict OO languages don't have this kind of flexibility.
As for Python, it might not be a bad idea, but there are a lot more Perl programmers out there than Python programmers. (Supporting both would be good, especially if via plugins.)
Mac interface woes (Score:4)
I hope they're planning to Aqua-ize the interface, or at least provide it as an option. The current preview is being ripped to shreds on all the Mac forums I read as ugly, nonintuitive, and just plain broken, especially in the design of the dialogs. Unfortunately, I doubt that submitting thousands of "it's not Mac-like enough" bugs to Bugzilla would necessarily help things.
However, if work keeps progressing on Fizzilla [mozilla.org] or the Rhapsody Yellow Box [mozilla.org] ports...sweeeeet.
Re:Too ambitious? (Score:3)
In terms of how the ambition helps Mozilla itself, I think the theory is that it will prove advantageous in the long run. Remember that the reason Mozilla pretty much rebuilt Netscape from scratch was that the Netscape 4 codebase was considered so scrambled that further development on top of it just didn't make sense. Sure, it's taken forever to see Netscape 6, but now that it's built on such a well-engineered codebase, future iterations should benefit from the fact that it'll be so much easier to ferret out old bugs and add new features. That's the theory, anyway.
Francis Hwang
Re:Why wasn't a message saying the art. was edited (Score:3)
Handling tons of bug reports (Score:3)
My conclusion is that a way of doing this is using the voting feature of bugzilla, and start by fixing the bugs with the most votes. Thus, people are encouraged to see if anyone else is having the same problems they have themselves, and the time developers have to spend on finding duplicates decreases. Those who have uncommon bugs will of course be run over by this scheme :-(, but my opinion is that it is more important to help lots of people than help only a few.
Comments anyone?
Cheers
//Johan
You don't want this (Score:3)
Perl together with Safe.pm is able to provide a security model that allows people to run untrusted applets, etc. But it is not as comprehensive a system as the browser, and more importantly it is not the same system.
Something like a browser should have a single security model that there is no confusion about. If you start matching unmatched security models, well welcome to the security hole game.
Perl is a great language.
It just isn't a great language to have client-side stuff delivered in over a browser.
Cheers,
Ben
PS JavaScript, BTW, is not a very good language IMHO. If x and y are both 2, then what is x+x? It could be 4 or 22, neither variables nor operators are typed. Bad decision.
PPS Some good points for JavaScript. A lot of web programmers don't know, but should, that JavaScript objects are virtually interchangable with Perl's hashes. JavaScript also supports full closures.
check it out (Score:4)
This statement above, is pretty darn exciting. While many people probably think that the browser wars were just about Microsoft wanting to dominate the client-side browser (and eventually maybe the server side), it was also about Microsoft maintaining it's stranglehold on the desktop operating system. Microsoft was scared that if Netscape became the defacto standard browser, app developers could eventually write to netscape API's, thus bypassing the Windows API and effectively rendering Windows irrelevent. The reason Microsoft was so scared of Netscape was the same reason Microsoft was scared of Java -- they would lose their monopoly on the API in which application developers would have to write to.
So Netscape supposedly "lost" the browser-war. Big deal. It's round two now and Microsoft should be really scared. AOL has released a web appliance running Linux and Mozilla code. No Microsoft there. Mozilla is completely modular, cross-platform, and open-sourced so developers can build apps around it once and have complete control. No need for Microsoft here, either.
Java was a "threat" in that it threatened the dependency on window's API's. However, Sun kinda messed that up by controling it. Mozilla is Open-Sourced, and can't be controlled (or embraced and extended).
These are exciting times. Mozilla may be exactly what is needed to wrench desktop applications control away from Microsoft. If developers start writing to Mozilla API's, that's the foot in the door.
Mozilla as a platform is a pretty darn exciting idea. Maybe the Web Browser really will eventually become "part of the operating system." ^_^
Buttons I want in Mozilla skins (Score:5)
The 6 basic navigation buttons I want in every skin are:
1) back
2) forward
3) up (shortens the url by one segment)
4) reload
5) stop
6) home
In that order. Mozilla has it *almost* right, but not quite (the up button is missing).
I also want to be able to define multiple "home" buttons and have them appear beside the usual home button, in every sense equal, and not have my own buttons relegated to a space-consuming "personal tool bar".
While I'm going on about my wishes... what about all that space to the left of the "help" item? I want to be able to put the location box there, saving a whole bunch of valuable vertical real estate.
Hmm - just one more wish today - when I minimize a tool bar, how nice it would be if the space to the right of the little tab were transparent, winning me back a tiny bit more vertical real-estate, instead of opaque, empty space.
Thanks in advance, skin hackers, for taking this seriously
--
Exporerzilla? (Score:4)
It seems to me this would take a lot of wind out of Mozilla's sails. Does the world really need two open-source browsers? And with a majority of the end-user installed base, an open MSIE could very well grab a larger chunk of developer effort.
Re:Too ambitious? (Score:3)
Even the early browsers had API's for plugins, API's for automation, etc. It's been quite possible, for quite a long time, to build applications that work entirely from the browser. All Mozilla does is make those applications significantly more powerful.
Re:Handling tons of bug reports (Score:3)
What would really fix that is a karma system
and the time developers have to spend on finding duplicates decreases.
Some net-community people (including me) do search for dups among bugs they haven't reported themselves, and I hope that saves the engineers some time keeping the bugzilla system clean and also reducing the change of duplicated coding work.
--