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.

http://philipp.wagner.name/mozilla-xforms/xforms-0.8.8b1.xpi

It requires at least Firefox 4 Beta 8 and works on Windows (x86) and Linux (x86 and x86_64).

Please test this version with your forms and report any problems you find! It helps us to deliver a great version of the extension for Firefox 4!

An (incomplete) list of changes is available.

Looking forward to your feedback!

Sent out my Mozilla Committer’s Agreement today!

Please consult the release announcement for a complete list of changes.

Known bugs:
Inline schemas don’t work. As a workaround, use an external schema. (bug #567628)

But for some time now I got a Python exception: gaierror: (-2, 'Name or service not known').  And no, it’s not my name servers, those are up and running. Causing the problem was the following line:

 boundary = mimetools.choose_boundary()

Somehow gethostbyname() screwed up (we were switched to new DHCP servers recently) and looking up our own hostname failed. At least it took me some time to look at the right place for that exception. When opening an URL you expect such an exception usually not inside a function giving you a MIME boundary :-)

After all, the XForms builds for Linux are up and running again, now for mozilla-1.9.2 and mozilla-central. Please give these builds a try and report any regressions you find as we plan to release a version for Firefox 3.6 around March.

Another quick note: XForms for Firefox 3.6 is on its way.

The XForms AddOn for Firefox 3.5. Download it now while it’s fresh :-)

The XPI contains binary components for Windows (32bit) and Linux (32 and 64bit).

Remember: this is an experimental development snapshot, so don’t be surprised if it kills your cat. But it should still be more stable than the previous release version, as we fixed some crash bugs.

I also added a bit of documentation on how to build Mozilla XForms from source at the Mozilla Developer Center.

Enjoy!

Mozilla switched from CVS to Mercurial (hg) with this release and removed the XForms extension from the core tree. We got a new hg repository, but it’s still empty (http://hg.mozilla.org/xforms). So what’s to do now?

1. Convert the extensions/xforms directory from CVS to hg.
2. Create a new hg repository on hg.mozilla.org for schema-validation and convert extensions/schema-validation to hg.
3. Make the XForms extension build with Firefox 3.5 (there has been some cleanup work towards Mozilla2).

To get started, I did the CVS to hg conversion for XForms and schema-validatio n.The results are available at http://philipp.wagner.name/hg. I mainly followed Gijs instructions for converting Venkman, so that’s the short version of how I did it:

1. Check out existing code from CVS
   $> cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -d xforms-cvs mozilla/extensions/xforms
2. Make sure your ~/.hgrc file contains the following lines:
[extensions]
hgext.convert=
mq =

   [convert]
hg.usebranchnames=0
hg.clonebranches=1

3. Convert all branches
   $> hg --encoding utf8 convert xforms-cvs xforms-hg-initial
   This may take a while.
4. Remove the [convert] section from your ~/.hgrc file
5. Create the authors.txt file with a mapping of CVS usernames to names and e-mail addresses.
   For a list of authors use
   cd xforms-hg-initial/default && hg log | grep "user:" | sort | uniq | cut -c14- > ../../authors.txt
6. Convert the default repository to the final XForms repository:
   $> hg --encoding utf8 convert --authors authors-merged.txt xforms-hg-initial/default/ xforms-hg-final

I chose to “merge” authors, by mapping multiple e-mail addresses to one (the current one). For schema-validation I did exactly the same and the result is available  in my hg repository.

The final step is go get it all compiling. Using hg annotate I found the relevant bug reports that changed things and I made the required changes to XForms, which resulted in the patch attached to bug #485734.

Now the XForms extension compiles and works as it did before on Firefox 3.5. What’s left is to get all those outstanding patches into the code. To check it out, use

$> hg clone http://hg.mozilla.org/releases/mozilla-1.9.1 mozilla-1.9.1
cd mozilla-1.9.1
$> hg clone http://philipp.wagner.name/hg/xforms extensions/xforms
$> hg clone http://philipp.wagner.name/hg/schema-validation extensions/schema-validation
Then building works as it did before.