philipp's weblog header image

The Future of Mozilla XForms

July 13th, 2011 · 7 Comments · English, XForms

I received a couple mails and comments lately about Mozilla XForms not being available for Firefox 5 (or on addons.mozilla.org for Firefox 4). I also have been thinking about the future direction the Mozilla XForms extension could and should take. This post tries to outline some of those thoughts.

Let’s start with the facts. On the development side, I have been the only person doing coding work on XForms for almost a year now (with great support from Aaron, Alex and Olli, who did all the reviews). Unfortunately, I’m very limited on time and it has not been much work at all (at least by the results; the various platform changes required me to dig much deeper into platform code than I every thought I would, and it took me quite some time to get used those very different areas of code). This makes development extremely slow and puts the focus mainly on “keep the thing working” rather than implementing new features.

On the user’s side, according to the feedback I get via mail and on the mailing list, and according to the download stats, there are still some users of the XForms extension. (The 0.8.8b1 XPI for Firefox 4 has around 300 downloads a month from my site.)

Finally, the environment side. The XForms extension is a binary component that uses many internal interfaces of the Mozilla platform. This makes it, as the past has shown, highly affected by platform changes. It has always been the case that some changes were required on every major platform release (formerly every .x release, e.g. 3.5, 3.6 etc., now every release, e.g. 5, 6, 7).

Since the 3.x-days, three things changed:

  1. No more stable APIs. This has been outlined in [1] and implemented with Firefox 4 (Gecko 2.0). This means we cannot rely on any API to stay stable for more than one major release.
  2. With the Rapid Release Process [2], the new development model since Firefox 5, a major release is released every 6 weeks and users are auto-updated to that release.
  3. Extensions with binary components must be at least recompiled for the new major version, even if no changes to the codebase are necessary. [3]

These three points put together mean that not only a new XForms release every 6 weeks is necessary, but also that a growing number of fixes for platform changes is needed.

You probably see the problem now. One developer that’s short on time has absolutely no chance to do a release every six weeks, and without that the Mozilla XForms extension becomes unusable every six weeks (as said before, users are auto-updated to the new major release).

So, what’s the conclusion? With the current situation, I will not be able to keep up the speed. If no other developers pop up, I don’t see a future for the Mozilla XForms extension. I personally will continue to use it in the project I’m working on (and that will stay on the platform Firefox 3.6 is based on probably), but I will not invest much time into the further development to make it compatible with the latest Firefox release.

Put the other way around, this means: if you are a user of the Mozilla XForms extension and need it to be supported on newer Firefox versions, you might consider joining the development (I will help where ever I can, and I am sure that Aaron, Alex and Olli do the same) or pay someone to do so.

As a final comment, I personally came to the conclusion that XForms as a browser plugin is dead. XForms as technology is still very much relevant, but not for all use cases thought of when initially standardizing XForms 1.0. One of them, replacing the “old” HTML4 forms, will probably never happen. HTML5 and its surrounding technologies make the browser much more powerful in a generic way. This makes it possible to provide a much greater user experience with server-side solutions than it was possible a couple years ago. The web and with it the browser market changed drastically over the last couple years, with more competitors and innovations happening at a much faster pace than ever before. By acknowledging this we can use the new opportunities the HTML5-Cloud-Buzzword-Web brings to provide an even better experience for the users of XForms — unfortunately, the Mozilla XForms extension will not be part of that experience.

 

PS: There is much discussion going on in the community right now about
add-on compatibility, including ideas like porting binary addons to
js-ctypes or using the Addon SDK (JetPack). Both options are not really
applicable to XForms, as it is probably unique in the way how deep it
integrates with the platform. Even if they were, a lot of engineering effort would be necessary to utilize those technologies. [4], [5]

 

[1] http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/18f49e75338e4ce0/f42915417230e621?pli=1
[2] https://wiki.mozilla.org/RapidRelease
[3] “We have and we will break add-on API compatibility with every release, certainly binary add-on compat. We will be adding major new features or doing serious re-architecuring with every release.” — Asa Dotzler at http://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_numbers_cognitive_disson.html
[4] http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
[5] http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctypes-is-the-way-to-go
This is a cross-post from the mozilla.dev.tech.xforms news group, please follow up there for the further discussion.

Tags:

7 responses so far ↓

  • 1 Chris H // Jul 18, 2011 at 16:01

    thanks for the update.

    If a little disappointing, it is perhaps a realistic snapshot of where things are at.

    I will always advocate XForms and its use and do not see HTML5 as a challenge to it – well not yet anyway. XForms should be encouraged, along with the XRX paradigm it is a very clean approach/solution.

    The comments regarding development and support of the add-on are very reasonable, especially given the addon is only useful in a FF experience.

    Alas, it seems the xforms addon is at an end.
    A big thank you to you and all the others before for your work and attempts to keep the addon alive.

    If I were competent to take on the development I certainly would.

    I will still develop XForms and will endeavour to find alternative approaches – XSLTForms is pretty decent for a general XF processor.

    All the best.

  • 2 Ray // Dec 20, 2011 at 10:43

    I agree with you regarding xforms as a plugin… it should be base function of the browser!

    The idea that I must allow code of unknown provenance to execute on my machine is ridiculous. XFORMS is declarative and its behavior is known. Javascript can do who knows what? But you know that. :)

    I’d help but I think I’d require alot of assistance, all my experience is on “backend” server type stuff.

  • 3 Philipp // Dec 20, 2011 at 12:52

    Making XForms part of the core browser was the plan initially (during XHTML 2 times), but it didn’t work out for a couple reasons. Some might be political, but many are indeed technical. As it turns out, it is not easy to create a declarative language that is simple to learn, understand and author while at the same time being powerful enough to allow for many great and crazy ideas to be implemented in the coming years. In the end, XForms, while being a huge and complex specification still doesn’t cover all use cases people can think of. For many use cases of the web taking a step back to a simpler forms language and augment it with the almost unlimited possibilities of DOM and JavaScript was probably the right decision.

  • 4 L. Jaffe // Nov 2, 2012 at 20:50

    It is obviously impossible to keep up with the frantic pace of Firefox releases. Short of developing a standalone application, perhaps the best approach for further development is to choose a Firefox release that offers the most potential and go forward with that.

    So far, the mozilla_xforms xpi is the only thing I have been able to find that works consistently on local file systems on different operating systems.

    I plan to continue the development of projects I am advancing, RIC (Rupestrian Imagery Captabase) and others, by turning to BaseX or eXist-db. Nevertheless, I still want to pursue an XForms solution that works with local file systems (i.e., no server required).

    It seems that 0.8.6ff2 is the fastest, followed by 0.8.6ff3; however, I found 0.8.7 did not work very well with RIC. I would be happy to send you the zip file, ric028.zip (1.1MB).

    I would be pleased if you would let me know which xpi you thought was the most stable and fastest.

    If there is anything more that could be done, I’d be very interested in continuing the good work.

    I have used the following:
    mozilla_xforms-0.8.6ff2-fx+mz+sm-linux.xpi
    mozilla_xforms-0.8.6ff2-fx+mz+sm-macosx.xpi
    mozilla_xforms-0.8.6ff3-fx+sm-linux.xpi
    mozilla_xforms-0.8.6ff3-fx+sm-macosx.xpi
    mozilla_xforms-0.8.7-fx-linux.xpi
    mozilla_xforms-0.8.7-fx-macosx.xpi

  • 5 Philipp Wagner // Nov 7, 2012 at 19:21

    L. Jaffe: The 0.8.6 and 0.8.7 versions should work equally well (for their respective Firefox versions, of course). But since all available versions require old Firefox versions, which contain tons of known security problems, I would not recommend to use any of those.

    I don’t think you’ll get happy with the Mozilla XForms extension in the long term. You cannot stay on ancient Firefox versions forever, and support for newer Firefox versions would require a lot of work (and I mean *a lot*, like currently the whole DOM implementation is being reworked, and it’s not fully clear if there will be even ways to hook the XForms extension into that any more after the work is completed).

    For your local-only solution, you might want to have a look at XSLTForms, which is a client-only XForms implementation that has rather good reputation, even though I have not used it myself yet.

  • 6 Firefox 19 integriert PDF-Viewer | virtualfiles.net // Feb 19, 2013 at 11:40

    […] wurde die Unterstützung für XForms. Dieser Schritt hatte sich schon vor über einem Jahr angekündigt, denn an dem stark von Browser-Interna abhängigen Code arbeitete nur ein Entwickler. […]

  • 7 Firefox 19 met geïntegreerde PDF-viewer | ct Magazine voor computertechniek // Feb 19, 2013 at 12:11

    […] ondersteuning van XForms werd verwijderd. De stap werd al een jaar geleden aangekondigd omdat er slechts een ontwikkelaar met de code van XForms bezig was. “Personally, I came to […]

Leave a Comment