MozillaZine

Slides from Brendan Eich's Mozilla Futures Talk at Developer Day Now Available

Monday March 1st, 2004

Last Friday saw the first Mountain View Mozilla Developer Day since the formation of the Mozilla Foundation. The Foundation's press release about the event gives an overview of the talks that took place and James "Kovu" Russell has posted a review of some of the presentations.

The slides from Brendan Eich's Mozilla Futures session are the first be available online. In the presentation, the Mozilla Foundation's Chief Architect outlined Mozilla's strengths and weaknesses and described a future strategy plan. Proposals include accelerating work on integrating SVG, implementing support for more scripting and programming languages (such as JavaScript 2, Python and Perl 5), creating a XUL builder plug-in for the Eclipse platform, improving native widget and desktop integration and setting up a new developer.mozilla.org site with programmer documentation. Collaboration with Opera and Apple to advance Web standards was also floated and several possible end-user innovations were discussed.


#1 SVG - yes please

by leafdigital

Tuesday March 2nd, 2004 12:10 AM

Reply to this message

I'm an Eclipse fan so an XUL interface builder would be cool and all (not that I have any particular desire to build XUL interfaces); so would better Java integration within Mozilla. Actually, if you could code Mozilla extensions in Java, maybe I'd be more likely to be interested in building XUL interfaces :)

But SVG is the really big thing IMO. Not because of 'rich' interfaces as one speaker was quoted (I'm sorry but I don't think rich means good - on the Web, I think rich means bad, and I think client applications are still the best way to go if you need something that's to be used frequently - Netscape failed to take over the world on the 'web as platform' premise many years ago, and there's *still* no reason why client applications should run within a browser). Simply because it's disgraceful that the Web doesn't have a proper, open, free vector graphics format.

I'm not saying that Mozilla is to blame for that 'disgrace' at all - it's an inertia thing from Mosaic, Netscape, Microsoft, and every other browser producer/company throughout the history of the Web. Just as a situation... I mean it's ludicrous. Here we have a format where people have a wide variety of screen/browser sizes - and we're using graphics that can't nicely be resized. Here we have a format where bandwidth is sometimes critical and every server hit adds a little time to page download - and we have to use a bitmap graphic in a separate file if we want something as simple as a rounded box (Mozilla-specific CSS extensions aside).

SVG won't solve everything but it would certainly be nice to have the option - and like everything else, Microsoft aren't going to lead the way. If Mozilla can get the ball rolling with full SVG support in a browser with widespread use, perhaps other people and finally Microsoft will pick it up, just as is happening with popup blocking etc.

By the way, another feature toward visual scaleability would be smooth bitmap resizing (bilinear or bicubic resampling). While still not ideal, this would at least give people the option to specify graphic sizes based on text instead of having to specify text sizes based on graphics. I'd like to see this introduced too - there are performance concerns but it could either be introduced as an option, or with 'bailout factors' (e.g. if the image being resized is small anyhow then use bicubic; if it's larger, use bilinear; if it's really big just use the current size). Perhaps this is already included as part of SVG support...? Hrm. Even if so, it would still be nice on standard IMG bitmaps. --sam

#2 Gah, so I also meant to say...

by leafdigital

Tuesday March 2nd, 2004 12:16 AM

Reply to this message

I'm really glad to hear that SVG is being seen as important. Is this likely to translate into actual development toward fully-working, included-in-default-build (or as easy-to-download extension) SVG support any time soon?

BTW I was also sort of wondering whether Mozilla really has the architecture in place to hand off rendering for generic XML formats such as SVG, rather than special-casing it; so that it would be feasible for, say, a random interest group (maybe the MusicML people for example, not that I'm saying they have any desire for this) to create MusicML support as a Mozilla extension that will allow it to render correctly within the XHTML page, layered as necessary, working correctly if the MusicML code is inline in the XHTML instead of in a separate file, etc...

Hopefully the answer is 'yes' but if not then IMO this would be something to aim for. Being the browser of choice for XML and an XML format development platform in general (not just SVG, MathML and whichever formats happen to be blessed by the Mozilla establishment) could certainly be a 'strategic' move, I would think.

#12 Re: Gah, so I also meant to say...

by dpol <dpol@swipnet.se>

Tuesday March 2nd, 2004 3:30 PM

Reply to this message

Exactly. What we need is a way to allow arbitrary "plug-ins" (for lack of a better name) to handle specific XML namespaces - Gecko would be our default for the XHTML namespace, while the MusicML people would handle their namespace. Gecko would simply be the XHTML renderer, on par with renderers for other markup languges.

It's a bright future, indeed. :-)

#13 Re: Gah, so I also meant to say...

by bzbarsky

Tuesday March 2nd, 2004 3:42 PM

Reply to this message

> BTW I was also sort of wondering whether Mozilla really has the architecture in place to hand off rendering

No.

There are some thoughts on how to do it, but the hard part is to do it:

1) fast (this is rather important) 2) preferably without freezing the internal rendering objects

Of course #2 means that any such renderer would have to be recompiled for every mozilla release (and probably for every nightly, really), just like SVG is.

#10 Re: SVG - yes please

by mmcmonster

Tuesday March 2nd, 2004 10:12 AM

Reply to this message

I, also, can't wait for SVG enabled in the default builds (Seamonkey/Suite, Firefox, etc.).

The only tracking bug I noticed is bug 122092 (Enable SVG Support), which looks dead -- it's a tracking bug with no dependancies. :-(

Any thought from those in the know on how close we are to getting SVG enabled by default? Any particular bugs we should watch?

#14 Re: Re: SVG - yes please

by MXN

Tuesday March 2nd, 2004 5:42 PM

Reply to this message

I usually monitor the n.p.m.svg newsgroup. It's at Google Groups: <http://groups.google.com/…tscape.public.mozilla.svg>

- MXN

#3 Re: Need help? Do it yourself

by lacostej <coffeebreaks@hotmail.com>

Tuesday March 2nd, 2004 12:42 AM

Reply to this message

I was disapointed to see no mention of Composer in the presentation. Daniel is doing a good job with nvu! I believe composing to be an important part of browser acceptance. It makes users eat their own food.

<OT> Brendan, I see that the browser is resized when playing the presentation. Do you use a 1024x768 desktop to display it, or do you combine this with another trick to get better display integration when using a projector? </OT>

#4 Eclipse + XUL!

by jedbro

Tuesday March 2nd, 2004 7:39 AM

Reply to this message

"creating a XUL builder plug-in for the Eclipse platform" Now that would be sweet!!!

#9 Re: Eclipse + XUL!

by jilles

Tuesday March 2nd, 2004 9:53 AM

Reply to this message

Especially if it is a backend for the gui builder that is currently being created.

#5 RE: COMPOSER

by mybarterpc <waltert7@verizon.net>

Tuesday March 2nd, 2004 7:55 AM

Reply to this message

I hope the lack of mention of composer doesn't mean it's discluded. It would be a real shame with so many people harnishing personal web publishing these days. Personally, if it has been discluded I hope this and other mentions of it here are cause for reconsideration.

#8 Re: RE: COMPOSER

by plwong

Tuesday March 2nd, 2004 8:19 AM

Reply to this message

I agree. My friends who don't really know programming (i.e. accountants, economists, etc etc) uses Front page to create bad codes. Only a few uses Mozilla Composer. If Mozilla's composer gets more advance, we can convince more people to use the composer and it'll create web pages with good code. Which does benefit Mozilla's goal to promote standard html etc you know.

#6 RE: XML ALL THE WAY

by waltert10 <waltert10@juno.com>

Tuesday March 2nd, 2004 7:58 AM

Reply to this message

Yeah, More support for XML foundations like SVG in Mozilla would really up the bar on the browser wars. And with FireFox being a perfect replacement for IE this could change things quickly.

#11 Reply

by Racer

Tuesday March 2nd, 2004 11:36 AM

Reply to this message

I too am exited of the prospect of an open-source 2D graphics language based on XML. I am really tired of having to resort to Flash (because its proprietary) or Java (because it seems like overkill), when something like SVG would fit the bill perfectly. Add to that the fact that SVG based interfaces might even be able to generated on the fly and could run on any Mozilla-friendly OS without the previously mentioned plugins.

#21 Re: Reply

by porter235

Wednesday March 3rd, 2004 4:22 AM

Reply to this message

SWF is NOT proprietary. the Flash editor is. If you want to make SWFs and use open source, you can. Check <http://www.openswf.org/> If you want to make SWFs and use XML, you can. Check <http://kinesissoftware.com/index.html> Hell, using that tool you could even write an XSLT to convert from SVG to SWF. enjoy.

#22 Re: Re: Reply

by porter235

Wednesday March 3rd, 2004 4:23 AM

Reply to this message

that said.. yea! for SVG... i too can't wait.

#7 GREAT SHOW, FANTASTIC ARTICLE

by waltert5 <waltert3@mailbr.com.br>

Tuesday March 2nd, 2004 7:59 AM

Reply to this message

All I have to say to this is KUDOS....there is nothing more I could think of right now that would do it justice.

#15 SVG rules

by stelt

Tuesday March 2nd, 2004 5:49 PM

Reply to this message

While at the mozdev-EU meeting (report: <http://mozdev.org/piperma…2004-February/000076.html>) I promoted my initiative to organize SVGopen2005 (<http://svgopen.steltenpower.com>) and had some interesting conversations about SVG. I'm glad to see SVG is also considered important in "Mozilla Futures"

#16 The Age of .Moz?

by atom

Tuesday March 2nd, 2004 10:12 PM

Reply to this message

Huzzah, motion behind SVG! I wasn't the only one to see the writing on the wall then :-P Good to know.

SVG/Rich Internet App support in Mozilla will match half the looming Longhorn/XAML/C#/.Net approach. The implementation side. What of the creation side?

An Eclipse plugin is certainly the right direction. (esp given the push for Java/Phython/Ruby support) But where will these SVG creations be, well, created? Will this Eclipse plugin import SVG's created in Sodipodi (<http://www.sodipodi.org>) or Inkscape (<http://www.inkscape.org>), or even Illustrator or CorellDRAW? Should there be a parallel push to bolster support for open source SVG creation utilities? An open source viewer of SVG is great. But we have to create them somewhere. If the Eclipse environment were to be combined with an open source SVG editor, this could be the analog to VisualStudio.Net.

Then the tricky question of "branding." How does an organization brand solutions which are possible through the use of myriad open source solutions? Microsoft is bound to have a new, nifty branding strategy (or maybe just .Net warmed over?) by the time XAML/C#/Longhorn comes to fruition. But if I'm to go to someone and say "well, you shouldn't go with the .Net route because x,y,z, but instead should use this solution which allows for a more open and cross platform solution" what should I call it? Mozilla Foundation Rich Application Framework based on SVG and XUL Enabled Through an Eclipse Environment doesn't really roll off the tongue ;) Mozilla Powered Solutions? MozApps? MozPowered? .Moz?

Questions with some time to be answered. I am very glad to see this is the direction the Mozilla Foundation is heading. As soon as I saw the announcements of XAML, immediately I thought of SVG+Mozilla. Okay. So first I thought, isn't this what Mozilla was all about back when I stumbled upon R6. But my second thought was that SVG+Mozilla could do it better and faster and in more places than XAML/Longhorn ever could ;)

Microsoft will present an "end to end solution" for the creation of their rich content apps. We are now seeing pieces of the open source solution of the same problem. Mozilla will provide a wonderful client. Eclipse will work wonderfully as the IDE. With an SVG creation solution and a name for the whole darn thing, the world of apps might get very interesting, very soon.

#17 The Age of .Moz?

by atom

Tuesday March 2nd, 2004 10:37 PM

Reply to this message

Huzzah, motion behind SVG! I wasn't the only one to see the writing on the wall then :-P Good to know.

SVG/Rich Internet App support in Mozilla will match half the looming Longhorn/XAML/C#/.Net approach. The implementation side. What of the creation side?

An Eclipse plugin is certainly the right direction. (esp given the push for Java/Phython/Ruby support) But where will these SVG creations be, well, created? Will this Eclipse plugin import SVG's created in Sodipodi (<http://www.sodipodi.org>) or Inkscape (<http://www.inkscape.org>), or even Illustrator or CorellDRAW? Should there be a parallel push to bolster support for open source SVG creation utilities? An open source viewer of SVG is great. But we have to create them somewhere. If the Eclipse environment were to be combined with an open source SVG editor, this could be the analog to VisualStudio.Net.

Then the tricky question of "branding." How does an organization brand solutions which are possible through the use of myriad open source solutions? Microsoft is bound to have a new, nifty branding strategy (or maybe just .Net warmed over?) by the time XAML/C#/Longhorn comes to fruition. But if I'm to go to someone and say "well, you shouldn't go with the .Net route because x,y,z, but instead should use this solution which allows for a more open and cross platform solution" what should I call it? Mozilla Foundation Rich Application Framework based on SVG and XUL Enabled Through an Eclipse Environment doesn't really roll off the tongue ;) Mozilla Powered Solutions? MozApps? MozPowered? .Moz?

Questions with some time to be answered. I am very glad to see this is the direction the Mozilla Foundation is heading. As soon as I saw the announcements of XAML, immediately I thought of SVG+Mozilla. Okay. So first I thought, isn't this what Mozilla was all about back when I stumbled upon R6. But my second thought was that SVG+Mozilla could do it better and faster and in more places than XAML/Longhorn ever could ;)

Microsoft will present an "end to end solution" for the creation of their rich content apps. We are now seeing pieces of the open source solution of the same problem. Mozilla will provide a wonderful client. Eclipse will work wonderfully as the IDE. With an SVG creation solution and a name for the whole darn thing, the world of apps might get very interesting, very soon.

#18 Another weakness

by ed_welch

Tuesday March 2nd, 2004 11:27 PM

Reply to this message

Mozilla has another weakness, which they didn't mention: All windows appear to run in only one thread (at least the GUI only has one thread). When one window does somthing that takes a lot of CPU time all other browser windows will hang until it's finished, including the newsgroup reader and composer. This is particularly noticible when you open a PDF document within a browser window. Acrobat reader seems to be particularly slow. In all fairness, IE seems to suffer from the same problem. But that doesn't mean it's not a problem.

#20 Single-threaded, & the utility of SVG

by leafdigital

Wednesday March 3rd, 2004 3:32 AM

Reply to this message

I think browsers have been (essentially) single-threaded as you describe since the dawn of time. I'm not saying that's necessarily a good thing but it may be a difficult situation to move away from; if you make a humungous chunk of single-threaded code multi-threaded it is probably going to suck and a lot of things are probably going to break. (Possibly including things like user javascripts, etc.)

IMO this will not be a major problem in Mozilla once Mozilla is split into separate processes. You mention newsgroup reader and composer - well, once we've all moved to Thunderbird for news reading and Nvu for composing, these programs will get their own thread(s).

BTW this is a response to a different post, but I really don't think SVG should be seen as a Flash competitor; it should be seen as a GIF/PNG competitor. I see the primary use of SVG as efficiently creating scalable graphics (ordinary stills) on web pages.

For example, SVG (if it were available) should probably be used for:

* boxes, curves, etc. that are part of the web site's layout, which are currently done with gif/pngs [should be done with inline SVG, or SVG files for background-images]

* fancy font tricks that are currently done using header .gifs (with or without nasty css background replacement tricks) [should be done with inline SVG in conjunction with downloadable fonts; I am unsure as to the state of implementation here, this is one important problem area]

* graphs, charts, and diagrams [should be done with inline SVG for very simple graphs or external files for more complex images]

* any other graphics for which vector creation is appropriate or rescalability is important; as time moves on and screen resolutions become much more variable than today, this would include most images that aren't sourced from photographs; illustrations, icons, etc. [should generally be done with external files]

--sam

#27 re: Single-threaded

by ed_welch

Wednesday March 3rd, 2004 10:09 AM

Reply to this message

I wonder though if anyone has actually investigated the effort required. Two seperate Mozilla windows should not have any dependancies, so maybe it's not as difficult as you think. The benefit to the user would be enormous, making Mozilla much more responsive.

#28 Re: re: Single-threaded

by bzbarsky

Wednesday March 3rd, 2004 12:41 PM

Reply to this message

> Two seperate Mozilla windows should not have any dependancies,

Oh, how woefully wrong you are:

var win = window.open("http://somewhere"); window.setTimeout("alert(win.document.links[0])", 10);

Supporting that requires either running on a single thread or lots and lots of locking during DOM access.

#19 SVG can't come soon enough!

by Chilliwilli

Wednesday March 3rd, 2004 12:15 AM

Reply to this message

Microsoft has it's own vector format on the horizon.. If SVG isn't quick it'll go unnoticed in a MS vs Flash war.

#23 Java for Eclipse, Server & UI should be a priority

by nochesbellas

Wednesday March 3rd, 2004 6:01 AM

Reply to this message

I'm a huge fan of scripting languages, and regularly use Javascript, perl, and I'm now getting into Python and learning Ruby. That being said, I'm also a developer who works on many big and small projects, and one thing I see all the time is that Java is being considered more and more as the de-facto language of enterprise applications.

I think Java should be the top priority as a programming language for Mozilla apps for the following reasons:

1. The Eclipse tool is written in Java, and plugins for it are written in Java. Most back-end applications nowdays (in the non-Microsoft world) are also in Java (Servlets/JSP, etc), so if we also make programming XUL/Mozilla with Java we give developers a single language to learn all the way from the front end to the backend, which is important to productivity.

2. Java is mature, stable, solid, high-performance (if you haven't done anything in Java and have only read others who haven't done anything with it either latelly, please don't comment on this), has a huge user base, and the specification is fully open (anyone can grab the Java spec and create their own Virtual Machine and Java APIs without giving a cent to Sun Microsystems). There's even talk this past couple of weeks of IBM and Sun teaming together to create an open-source version of the Java spec. Bottom line: Mozilla can benefit for many years to come from the Java platform, and as most enterprise developers know, Java and Eclipse are the answer to .Net.

3. Let's forget the holy wars among ourselves for a second. Sure perl is awesome for text-processing and other tasks, but it syntax is something that no enterprise developer creating a 100,000-line application should use. Perl has its purpose as glue, I wouldn't use it for large-scale apps (although I'm not saying it cannot be used for large-scale apps, of which there are obviously a few out there). My point is: Java is easy, object-oriented, and it promotes good, clean, code.

4. Java has a built-in documentation system called JavaDoc. This is extremelly important in open-source projects where documentaton usually takes a back seat. JavaDoc is an incentive for programmers to spend a little time and write documentation. Bottom line: Java promotes better documentation.

5. Java is extremelly cross-platform, and extremmely Linux and Windows friendly, and there are great mySQL and postgress JDBC drivers available.

6. Java can play real well with both JSP (Java Server Pages) and PHP (which I think is a great technology by the way).

7. Java has the best XML and Web Services support of any platform out there, even Microsoft. Most XML/SOAP/etc tools are written for Java. And Web Services is the future of distributed apps.

8. Java can play nice with scripting languages to further enhance productivity. For example, there's JPhyton, and nothing stops perl from being the orchestrator of Java programs on the back end.

9. Java is fun to write programs to, and many sophisticated things (like threads and pools) are dead-simple to do in Java. Give it a try, I did and I have to admit that I think twice before doing anything in C or C++ anymore!

10. This is smoething that most hard-core developers seldom think about, but it is one of the most important things to think about: Java has the minds and wallets of the people who take/make decissions, i.e.: upper management and marketing. They might be boneheads (from a developer's point of view), but the bottom line is that if they are not sold on something they won't do it, and today besides technologies like Linux, XML, Mozilla, PHP, Perl, Ant and mySQL to name a few, Java is probably one of the few things that has gotten wide industry support. IBM as everyone knows has a huge investment in Java and Linux, and so does Oracle, Sun, and many other industry giants. So if Mozilla can piggy-back to Java's mindshare and benefit from it, so be it.

#24 Cool slides!

by sgifford <sgifford@suspectclass.com>

Wednesday March 3rd, 2004 6:54 AM

Reply to this message

The presentation was very slick; a nice showpiece for how an app can use Mozilla effectively. Anybody know how this was put together? Hand-crafted JavaScript, or does one of the presentation editors support something like this? If not, it would be fantastically cool to have an "Export to Mozilla" option in the various Free presentation editors.

#25 The Age of .Moz?

by atom

Wednesday March 3rd, 2004 7:19 AM

Reply to this message

Huzzah, motion behind SVG! I wasn't the only one to see the writing on the wall then :-P Good to know.

SVG/Rich Internet App support in Mozilla will match half the looming Longhorn/XAML/C#/.Net approach. The implementation side. What of the creation side?

An Eclipse plugin is certainly the right direction. (esp given the push for Java/Phython/Ruby support) But where will these SVG creations be, well, created? Will this Eclipse plugin import SVG's created in Sodipodi (<http://www.sodipodi.org>) or Inkscape (<http://www.inkscape.org>), or even Illustrator or CorellDRAW? Should there be a parallel push to bolster support for open source SVG creation utilities? An open source viewer of SVG is great. But we have to create them somewhere. If the Eclipse environment were to be combined with an open source SVG editor, this could be the analog to VisualStudio.Net.

Then the tricky question of "branding." How does an organization brand solutions which are possible through the use of myriad open source solutions? Microsoft is bound to have a new, nifty branding strategy (or maybe just .Net warmed over?) by the time XAML/C#/Longhorn comes to fruition. But if I'm to go to someone and say "well, you shouldn't go with the .Net route because x,y,z, but instead should use this solution which allows for a more open and cross platform solution" what should I call it? Mozilla Foundation Rich Application Framework based on SVG and XUL Enabled Through an Eclipse Environment doesn't really roll off the tongue ;) Mozilla Powered Solutions? MozApps? MozPowered? .Moz?

Questions with some time to be answered. I am very glad to see this is the direction the Mozilla Foundation is heading. As soon as I saw the announcements of XAML, immediately I thought of SVG+Mozilla. Okay. So first I thought, isn't this what Mozilla was all about back when I stumbled upon R6. But my second thought was that SVG+Mozilla could do it better and faster and in more places than XAML/Longhorn ever could ;)

Microsoft will present an "end to end solution" for the creation of their rich content apps. We are now seeing pieces of the open source solution of the same problem. Mozilla will provide a wonderful client. Eclipse will work wonderfully as the IDE. With an SVG creation solution and a name for the whole darn thing, the world of apps might get very interesting, very soon.

#26 oops. sorry.

by atom

Wednesday March 3rd, 2004 7:24 AM

Reply to this message

Not sure how my comment got posted 3 times, but I apologize for it!

#29 end user innovations: annotations

by bmartin79

Wednesday March 3rd, 2004 3:28 PM

Reply to this message

Perhaps I am misunderstanding what they're getting at with the annotations not sure... But so what about annotea ( <http://www.w3.org/2001/Annotea/> ) which already had a mozilla project a while back ( <http://annozilla.mozdev.org/> )

#30 end user innovations: annotations

by bmartin79

Wednesday March 3rd, 2004 3:42 PM

Reply to this message

Perhaps I am misunderstanding what they're getting at with the annotations not sure... But so what about annotea ( <http://www.w3.org/2001/Annotea/> ) which already had a mozilla project a while back ( <http://annozilla.mozdev.org/> )