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

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>

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

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.

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.

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

While at the mozdev-EU meeting (report: http://mozdev.org/pipermail/eu/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"

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.

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.

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.

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.

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.

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.

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.

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

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/ )

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/ )