Mozilla 2.0 platform must-haves

  1., a versioned shared library with minimal, frozen, documented API exports, and fast intra-library calling convention code (so small footprint compared to today’s “GRE” or “XRE”).
  2. xulrunner/xulrunner.exe, so you can write ‘#! /usr/bin/xulrunner’ at the top of a .xul file and get busy.
  3. XUL 2 and XBL 2 — standardized specifications, greater binding language power, more scripting languages, iTunes-like widgets, and working remote XUL/XBL.
  4. SVG support to a useful level, not necessarily the whole 1.1 spec.
  5. Web Forms 2.0.
  6. XForms Basic (or ultra-Basic, details TBD — the heavyweight item is Schema-based validation) support as an optional, downloadable extension.
  7. JavaScript 2.0 support, including ECMAScript for XML support.
  8. Python support, perhaps via Mono (if so, along with other programming languages).

That’s a good start. Comments?


65 Replies to “Mozilla 2.0 platform must-haves”

  1. #4 is overdue for all browsers
    #8 scares me _only_ for the potentially huge installer file. If it were optional this would be incredibly cool. If it were optional developers would have a headache. This leads to the question: What is the projected ‘average bandwidth per connection’ at the projected time of MOzilla 2.0’s release?
    Exciting stuff over all. Any word on XHTML 2.0 support as well?

  2. 9. Working Web Services support 🙂
    10. A more advanced, scripting controlled caching system. Cookies are too simple and need to be able to store data structures. This is needed for:
    11. Provide APIs for offline/online web applications so they can store and update data at a later time.

  3. Brendan,
    About the SVG support, the W3C SVG Working Group issues normative profiles of SVG, and I would encourage the Mozilla SVG folks to look at these in order to have a well-defined SVG feature set implemented.
    For instance, SVG Tiny (the smallest profile) is having great momentum right now in the mobile industry where it is being adopted by both major phone manufacturers and carriers. SVG Tiny is also evolving to version 1.2 where scripting support is added, along with a few select new features from SVG 1.2.
    You might want to look at SVG Basic too, which is the intermediate profile between SVG Tiny and SVG Full, where the number one feature taken out is the filters module.
    I know you have concerns about interoperability in the SVG world, but shooting for a well-defined normative subset of SVG would go in the right direction.
    Antoine Quint
    W3C SVG WG Invited Expert

  4. Hmm. What do you think about Parrot (Perl 6) support? Soon, Parrot will be something like stabile, and the hope is that it will support a lot of languages, includes Python. I would give it a chance, sounds good.

  5. Printing
    I believe a better print support will help us in a corporate environment. Up to now the printout is only second grade quality. But it would make the live much easierer if the documents designed for the browser would look also professional on paper. A lot of programms ouput html as a one of their export capabilities so it would be nice to start to write the user documentation from this in html, give it to the customer electronically, and have the paper manual just a print button away. Currently Open Office does a good job with its export to pdf capability. Every time I use it I have a warm feeling for the OO developers and wonder why it doesnt work in mozilla.
    When giving that html based documentation to a customer, one faces always the problem that it is usually more than one file. So you are never sure that all images are copied together with the primary document. In order to keep them tight coupled I see currently two options: compressed help files (*.chm) or pdf. Displaying compressed help files within mozilla would be a dream and would save companies a lot of money when they can migrate their electronical manuals to Linux. If chm is outside the scope due to political reasons than at least the capability to create and transfer compound documents would be nice. Mozilla has their own help system but its not very usuable to display help files for other products.

  6. No to Mono, I installed GNU PNET last week and am thoroughly unimpressed, I will not be installing any Microsoft .NET runtime, precompiled .dll’s or compromising file system security for the priviledge. Microsofts .NET framework is nothing more than a virus.

  7. What are iTunes-like widgets?
    12. Native database support.
    13. Update to the latest RDF spec and add scriptable RDF.
    14. all of the points (or most of them) available as part of the activeX control to help ease the transition from IE environments.

  8. I think item 2 is _by far_ the most important one. A corollary item, extremely important for xul-based standalone apps based on item 2 would be non-rectangular transparent widgets.
    I know that is an editing-in-browser issue, but I do believe an extended version of Midas is absolutely necessary.

  9. gcc offers a java virtual machine via gcj. This is portable across many systems and it uses the Boehm garbage collector (same as Mono). From a security standpoint, gcj would give Java’s sandbox model. From a java applet support standpoint, it would make java applet startup a first-class citizen. Very speedy startup. Also, it would yield good mind-share with red hat (who seems to be dedicating several red hat employees towards gcj/classpath).
    Python support can be provided via Jython which is much older than the .NET python implementation.

  10. Regarding Bernd and printing – at IBM, I get a lot of Mozilla printing issues from customers, and usually we have to find workarounds since no ones works on that code.

  11. 4 is most important i think. It can be used everywhere and there is no way to hack it other way.
    1 is also important. But ability to use shared GRE would be fine for me.
    15) Ability to change xul/xbl “in fly” (for eg. change language in fly, run extensions in fly…)
    16) Better debugging. There is no way for ordinary man to find out why gecko hanged onload. No info, no log…
    17) finish XPCOM interfaces for printing, zip/unzip, jar/unjar

  12. We already have Python integrated with XPCOM, thanks to Mark Hammond and Active State. If nothing better comes along in the way of a unified runtime, we will fully integrate Mark’s work so you can write <script type=”application/x-python”> in XUL.
    Whether Python support will be bundled in libxul or not, I’m pushing for a scheme that lets extension languages be loaded dynamically. So if you have connectivity or can deploy an extra file, you should be able to use Python as well as JS from XUL. That’s my goal, at least.
    See my next entry for the Mozilla 2.0 “managed code” virtual machine goals that any would-be universal runtime has to meet, or come close to meeting, to win.

  13. Yes, with Python in the standard package, I hope it would be possible to write mozilla applications using python. I mean with no name space, and having to import source from xul files are really pain in the neck. JS might be ok for web applications but it is really too limited for stand alone applications comparing to other full blown languages in term of language features and
    libraries. And LIBRARY is very very important for mozilla application to flourish.
    But how complete will the python support compare to javascript?

  14. 1 of 2: Documentation.
    2 of 2: Test suites.
    Rationale (I’m not saying this is definitely so; please point out where I’m wrong):
    1. Establishing trust and newbie productivity on a platform is more important than whether a platform can technically do any given thing out of the box, or even at all.
    2. Documentation and lack of bugs compared to that documentation is more important for establishing trust and newbie productivity than anything else.
    3. Leaving platform documentation to be written and matured as an exercise that occurs after a whole bunch of new coding’s mostly been done, or leaving platform documentation to other than the platform builders, will result in it getting to decent quality well after the platform is launched marketing-wise.
    Have just two absolute must-haves for a next iteration of moz-as-platform:
    o Productivity focused documentation.
    o Test suites.
    More specifically, I advocate that the platform developers spend a really big chunk of their time (50% or more), up to a 2.0 platform launch, focused on building a fairly uniform quality, and fairly unified, official platform documentation set. And that they follow a rule that anything that’s embarassing to document, or embarassingly/idiosyncratically complex to document, is preferably not documented as is but is either fixed, or has any mentions removed, or at least reduced to links to documents that are outside the official platform document set.
    Whether or not a particular element like Web Forms 2.0 gets in to the point-Oh release of the platform will then be as much a function of how it contributes to a less embarrassing or idiosyncratic platform documentation set (and hence newbie developer experience) as a function of how it contributes some other theoretical “must-have” feature.

  15. GCJ isn’t a JVM, it’s a compiler for Java (source or bytecode) to native code. GIJ is an interpreter, but sans JIT, so tending to poor performance. The gcjwebplugin provides an appletviewer-alike, but it requires that gcc/gcj be installed — a tough sell indeed for the download-size crowd.
    Requiring that gcj be installed in order to run applets or cross-platform mozilla extensions is a non-starter, I think. It’s huge, it’s GPL-only, and it further requires cygwin to be in place on Windows.
    Java also has no library-versioning story, which is pretty painful for an evolving platform like Mozilla’s.

  16. > JS might be ok for web applications but it is really too limited
    > for stand alone applications comparing to other full blown
    > languages in term of language features and libraries.
    > Posted by: AC at June 12, 2004 11:22 PM
    And yet, JavaScript is the nicest language I have ever worked with. Both its syntactic and object-based nature are so easy to work with and to extend, via the prototyping mechanisim and the new getters & setters feature. Its language features should be added to and an “inline” library-loading feature should be implemented. From my perspective, it is hard to understand why there is so much talk of replacing JS rather than of improving it.

  17. I think it would be good if this dicussion could be moved to the newsgroups. That’s more suited for it, and more official.
    That said, i would like a better toolkit. only one, not xpfe and toolkit. Also, I would like it to have utilities for extensions/apps. Like a standard menu set (file, edit etc). And a more centralized localization system would be nice too. No need to have multiple places where ‘copy’ is defined.

  18. Xulrunner — Nice name, I think this will be big.
    I’d like to hear more about the relationship between the current embedding API and the API that will be available in xulrunner.
    Since the files will have to start with #! they will no longer be valid xml files, so a lot of XML tools will probably not be happy about it. Any way we can have xulrunner activate just based on the file extension instead? That way the XUL files can stay pure XML.

  19. The technical design for xulrunner is still being hashed out, but I’m pretty certain that the #! syntax will not be the “normal” way to get XUL apps bootstrapped. We want a simple format that can be shipped to all platforms, and #! is *nix-specific.

  20. Right, #! is for Unix only, and then only if you want an executable file that can be run from a naive shell, or via exec(2). The #! example is evocative of what should be possible with xulrunner: small to medium scale, easy to write and extend, XUL desktop applets.

  21. For xulrunner I’d expect automatic reading of a well-known file (xulstart.xml?) and command-line parameters.

  22. In reference to #3 (XUL/XBL upgrades).
    Please consider some kind of compatibility with XAML, and MXML. I’m not asking for integration of the CLR and the Flash plugin directly into the browser engine, but anything that will enable developers to leverage their code in any way to make an XUL version of their UI something less than a total rewrite. XSLT is not the answer either.

  23. XUL has to be compatible with its earlier versions, first. Second, XAML and to a lesser extent MXML are proprietary, moving targets with closed-source implementations. Supporting only “some” XAML or MXML compatibility is unlikely to satisfy anyone.
    With a full XAML specification and a stable target, and assuming we integrate Mono, we could consider it, but it’s extremely low priority right now.
    MXML is more likely to be stable, but it aped XUL, incompatibly. Imitating it in a XUL 2 makes less sense than trying to emulate it faithfully. AFAICT, we haven’t the volunteers to do a complete MXML emulation. Anyone with the knowledge and the hacking skills, please mail me.

  24. About JavaScript 2.0 support… it appears, at least to the outsider, that work on the prototype implementation (Epimetheus) has ceased sometime in 2003, if not earlier. Are there any concrete plans within the Mozilla Foundation on building a JS2 implementation with E4X support?
    Any thoughts on basing an implementation on the parrot VM?

  25. I would like to see the ability to talk to Mozilla from outside Python code. A program I am writing allows importing contacts from various data sources. I can do Outlook and Evolution easily, but have given up on Mozilla contacts.
    In theory I need to use XPCom with the PyXPCom wrapper but I challenge anyone to actually get that working on Windows, Linux and Mac and have a redistributable program. (There are no binaries of PyXPCom for example).
    Importing from Outlook is a breeze!

    There is PyXPCOM binary for Debian Woody, perfectly working. Yes, PyXPCOM installer for Windows, Mac, etc. is sorely needed, but it’s not that far. Rewriting Debian rules file to RPM spec would be the first thing to try.

  27. Christopher: yes, but E4X will be in SpiderMonkey sooner — see bug 246441. The new JS2 plan is to bootstrap off of the JS-in-JS project I started under js/narcissus. More on that soon, but it’s important to sync with the ECMA folks, because Edition 4 may not be what was drafted last year.
    I was underwhelmed by Parrot when last I looked, but someone convince me with demos, benchmarks, portability claims, stability measures, etc.
    claus: yes, #5 _and_ #6. See “The non-world non-wide non-web” entry in this blog. XForms is not for the web, but it could prove useful for certain intranet customers.

  28. > Please no Mono. No .NET on free platforms.
    What is the connection between the first sentence and the second? What is the meaning of “free” in the second?

  29. I have a platform specific request for 2.0. Mozilla 1.0 was build around the mac os 9 to X transition and we have some bugs related to that.
    I would like mozilla to switch from Quickdraw to Quartz for its rendering. This is a hug amount of work that needs to be done, because the Quartz API are updated and debuged, quickdraw’s are no more. This is one change i think should happen if mozilla wants to perdu on os X.

  30. Get SVG support to official builds/milestones is functionality I’m looking forward for about a year!!
    The soon the better, SVG basic will be enough to first release, but also current support is not so bad (on GDI)

  31. I would like to see a world of platform neutral web standards, where each OS has a browser implementing those standards. I would like each OS to have a browser which is tied to, and integrates fully with, that platform. IE on Windows, Safari on Mac, and Firefox on Linux.
    Moz fought IE and lost – you can’t compete with MS’s resources on their platform (playing field), they just arent going to let it happen, ever. And it doesn’t matter, because in the long term Windows is dead as a platform (Free Software will prevail). So, don’t waste the resources. Moz should concentrate on Linux and Gnome. There are good ruminations in this direction, but I don’t see it really happening as long as Moz clings to the cross platform dream.
    I would say go-Mono (heh), but even with an educated opinion, the IP issues are scarry. Java has a huge developer and vendor base – GCJ/GIJ/Classpath will mature. I say work with RedHat to move it, and Linux, forward.

  32. 1. A an integrated Web application / classic application usage model. What is the interaction model of a native application vs. a web application. Ask yourself what a web application user’s interaction is with the client OS. Should the gui shell be the web browser? Should the web browser be the gui shell? etc. This re-factoring is probably down the road, but it pays to think about it now in concert with gnome (or other).
    2. 3D display and interaction. Sounds way-out and has many issues with scaling across device capabilities. However where can / where should 3D be integrated into the typical 2D layout interaction process. Perhaps 2D layout of real 3D widgets. There is a level of richness if you have 3D widgets and animation that isn’t present with today’s web experiences. If you want it to be used then don’t make special plugins required. This goes hand-in-hand with animation support, minimal update, and a buffered, “frame rate” updating model.
    3. A smart auto-installer for Windows that functionally replaces IE without any user intervention (beyond clicking “yes”). In other words, installs, imports favorites / history / cookies etc, closes IE and relaunches at the same page / position on the screen. Don’t even ask for install location, just do it.

  33. You may consider Jython (Python-on-Java) instead of going woth Mono for Python. Java is supported anyway…

  34. Printing definitely is a big issue.
    So many new features are added. Should mozilla break into some small applications?

  35. What I’d like to see by Mozilla 2.0?
    1. A nice juicy rewrite of MIME-related code, better representation of MIME messages (internally as objects and the external expression in the front-end of MIME structures), etc.
    2. Fixes for the more outrageous layout bugs, like 5016 (absolute-in-relative positioning totally broken) and 174470 (RTL border-collapse totally broken). Or more generally, a more mature bug-free gecko.
    3. Correction of the utterly broken text selection/caret movement algorithm, specifically with respect to RTL text

  36. In regards to Mozilla as an app development platform: XForms will indeed be good for intranet applications. Printing is a sore point though. How about something akin to apache FOP technology (XML->XSLFO->PDF) inside Mozilla for printing power on the client side?
    It is wise to consider intranet/app developers – a killer app that is built on mozilla may be _the_ impetus to get the average joe windows to download and install moz.

  37. SVG!
    I think interactive SVG is the future of lowbandwidth web-style communicating. The WWW is SOooo rectangular. I’d like to see that begin to change. down with bitmapped phony effects

  38. I know python is nice and all for certain things, it is not a replacement for C++ in terms of speed. For example think of scientific applications or image editing, video processing/manipulating, etc. It is possible to code these things in C/C++ (and definitely using C++ in mozilla should be as easy as using javascript for development), nobody wants to code in C++ and deal with memory management. C# (only on windows, not with mono) is as fast as C++, and Java is good enough most of the time (sometimes unacceptable though).
    Complex applications need this. If you want to compete with XAML/.Net/etc.

  39. What about a language like Scheme ? The language is small and a lot of good/fast interpreters are already available.

  40. Personally, I’d like to see LDAP support return (ldap://) to browse a Directory. but that’s a small client-base I’m sure.
    My only pet-peeve not mentioned so far is the lack of consistency in the UI. If I had any coding skills whatsoever I’d help out, because the lack of consistency is frustrating.

  41. An advanced language group is working on a new VM. It is the Alice sub-group of the Mozart Oz language project.
    There’s little public web documentation right now, just a roadmap and a wiki. However, there is real, honest code in CVS, and the thing is coming along. It’s got advanced features. Talk to them! Their cool VM might be just the thing Mozilla is looking for.

  42. Based on three years of developing Komodo on top of Mozilla, here are some of the top items I would suggest:
    – a working plugin architecture (I know there is a working group on this already).
    – *xpcom for other languages built in (I like the mono idea also)
    – backwards compatibility for xul/xbl/js/etc between point releases. With moz 1.x, we’ve had to face behaviour changes every point release, some being pretty tough to discover.
    – better customization for applications. by this I mean pref directories, splash screens, other low level items that we have patched to enable.
    – real inheritance in xbl and the ability to call on parent methods without hacking and ugly code
    #2 in your list isn’t really to xml spec is it?

  43. One thing that the Mozilla 2.0 platform should definitely have is a better (user) profile system. From the feedback I am getting, the majority of the problems people are having are profile-related. This can get very annoying for many when they lose their mail, bookmarks, addresses…
    Som, IMHO we really need a more reliable way to store profile data (so that the chances of data loss are minimized) and one that makes backing up and restoring the profile and settings easier and “machine neutral”, i.e. can easily be moved from one PC to another.

  44. I wouldn’t change a thing on your list (I’d tend towards mono to get to python than python without mono.. also, to compete with microsoft’s avalon I wouldn’t skimp on an SVG tiny implementation – the graphical capabilities of a full blown implementation are really the only way to compete).. a couple of others to add though from my graphics/application development point of view:
    1. development environment – the potential for a unified server and client development environment makes me giddy. An environment built on the mozilla 2.0 framework, for the mozilla 2.0 developer community would rock.
    2. hardware accelerated rendering – in particular with the more intense graphical requirements of a next generation platform.
    I’m looking forward to getting my hands dirty as things start to roll… especially if they roll the mono way.

  45. How about an ability to block access to certain features in Mozilla? I run an internet cafe running IE 6.0 using Windows’ Group Policy Objects. It’s not prefect, I had to use a resource hacker to remove access to part of the IE GUI for complete security.
    Mozilla could have its own locking utility to do the same thing and works on all platforms?
    A coworker worked with Opera when they started out to build a locking mechanism for them. We used this locked down Opera for a while but we couldn’t afford the cost and it was when Opera’s HTML renderer wasn’t up to par with IE or Mozilla’s. Not sure if Opera still have that locking down feature though.

  46. Mozilla is a great browser. To finally conquer M$IE bullshit, people really need a reason to download Mozilla. So make this really great browser better!!!
    Some parts of the browser like the download manager can be enhanced. Perhaps can the interface a little bit more popularised to make Mozilla more attractive.
    #7 Javascript should also use the most common M$IE specific script tags.
    #8 Please don’t insert not very useful stuff. If people want this they can download themselve.
    Finaly: Make demonstration sites with the new features included in the new 2.0 browser. So people will see what kind of wacky browser M$IE is and webpage designers can make better sites.

  47. Just like XPCOM models COM I don’t think all microsoft work is bad.
    If mozilla could provide something like .NETs JScript (that is access to all .NET objects) you can use Mozilla as a rich client for databases etc…
    I don’t think you need a better language but more libraries that you can call. So I would like the Mono option (see for some nice XML examples using C# but you could replace that bij javascript)

  48. How does this list stack up now we are well into Fofire 1.0?
    Build With Steel

  49. * XULRunner First ! (with maximum optimisation)
    * XML everywhere :
    – Language Files
    – Configuration Files
    – Log files ?
    – XUL (though XULRunner)
    – SVG
    – X3D (too late for VRML)
    – CSS x (Why CSS3 isn’t XML ?! stupid…)
    * Finish with XUL Compiler / XAML Transformer 🙂

  50. Mozilla x.x should have less bugs, that’s key to success. I’m struggling, day after day, with Mozilla bugs and one has to agree, you get a little sick of some of them not being fixed 🙁

  51. I’d suggest not using mono / PNET. Not cause they’re microsoft, but because of their horrid support for closures. JScript.Net flat out drops closures. F# was a demo language that supported them but preformed horribly. it’s my understanding that the activestate port of perl to .Net was canned because the closure issue made it so slow.
    as for parrot, when was the last time you looked?

Comments are closed.