The Future of Mozilla XForms

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The Future of Mozilla XForms

Philipp Wagner-4
Hi!

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, two things changed:
a) 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.
b) 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.
c) 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.


Ideas, thoughts?

Philipp


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
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

Sebastian Siennicki
Tantek Çelik

"Is XForms dead on the Web? If not, tell me what are you doing, with
which browser/plugin, and what public URL."

https://plus.google.com/109182513536739786206/posts/GQQwvwUz5HB#109182513536739786206/posts/GQQwvwUz5HB



_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

Jozef Aerts - XML4Pharma
I have been working with different XForms implementations, some of them as
browser plugins, other server-side based, others as converters.
You can find a full list of those I have been using at:
http://www.xml4pharma.com/ODMinEDC/browsers.html

At the moment I mostly still use Chiba (server side) but should (when time
permits) upgrade to its successor BetterForm.

I too have the impression that XForm plugins for browsers is currently not
the future, because:
- browser suppliers (MS (IE), Mozialla (Firefox), ...) are not really
interested in natively supporting XForms
- each new version of the browser requires the plugin to be adapted by the
plugin developers
- browser suppliers do not seem to be able to keep their API stable, which
makes life extremely difficult for plugin developers

With best regards,

Jozef Aerts
XML4Pharma



----- Original Message -----
From: "Sebastian Siennicki" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, July 14, 2011 10:57 AM
Subject: Re: The Future of Mozilla XForms


Tantek Çelik

"Is XForms dead on the Web? If not, tell me what are you doing, with
which browser/plugin, and what public URL."

https://plus.google.com/109182513536739786206/posts/GQQwvwUz5HB#109182513536739786206/posts/GQQwvwUz5HB



_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms


_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

Alain Couthures-2
In reply to this post by Philipp Wagner-4
Mozilla XForms has always been the reference implementation for
XSLTForms. Its minimal rendering was much appreciated.

XForms is a client-side specification and plug-ins are still the best
ones for implementing some features not available with Javascript for
security reasons.

XForms is more powerful than HTML5 forms and there are many companies
knowing this.

JSON support in the future XForms recommendation will help, for
example, to directly use XForms with NoSQL databases such as couchDB.

Best regards,

-Alain
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

Robert C. Leif
In reply to this post by Philipp Wagner-4
On Jul 13, 5:46 am, Philipp Wagner <[hidden email]> wrote:

> Hi!
>
> 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, two things changed:
> a) 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.
> b) 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.
> c) 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.
>
> Ideas, thoughts?
>
> Philipp
>
> 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/thr...
> [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 athttp://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_...
> [4]http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
> [5]http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctype...

I believe that XForms has been of considerable use including
motivating much of its capability to be included into HTML5. I suggest
that XForms be repalced (resurected) as an add-on to HTML5 and XHTML5.
One deficiency of HTML5 is that elements defined by user defined types
cannot be included in HTML5. Others with greater expertise can suggest
other elements and functionalities from XForms to be included in
HTML5. Since Microsoft has included an HTML5 XML schema with the
latest version of Expression Web and possibly Visual Studio or other
development tool, a means to augment HTML5 (XHTML5) is available. The
other part would be a plug-in for one or more browsers that support
HTML5 (XHTML5) .
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

kevin.coonan (Bugzilla)
In reply to this post by Philipp Wagner-4
On Jul 13, 8:46 am, Philipp Wagner <[hidden email]> wrote:
> Hi!

Thanks for all you have done.

> 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

I agree, but for a different reason.  Browsers should support it 'out
of the box.'  While this isn't a realistic expectation for IE, there
are other browsers out there that a lot of people use.  E.g. Opera,
Chrome.  These seem to have more reasonable corporate backing.  Have
you been in contact w/ the respective browsers?  Adding XForms as a
routine item (at least in non-M$ browsers) will spur the adoption of
XForms (or at least break down one objection for use).

I also agree with your comment about HTML5.  XForms transformation to/
from HTML5 forms will likely be needed.  This is unfortunate, but it
isn't likely that w3c will make changes to make life easier.  With
architectures like XRX for complex domains (e.g. healthcare,
biomedical research) the need for the model + constraints (which can
be discovered at run time) is critical.


> Ideas, thoughts?
>
> Philipp
>
> 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/thr...
> [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 athttp://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_...
> [4]http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
> [5]http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctype...

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

mozillaxforms
Hi,

We were not able to convince Mozilla or Seamonkey to embed XForms back
when XForms was showing a lot more promise and when Mozilla was the
enterprise browser of choice (after IE, of course).  Now that XForms
and XHTML are losing ground to HTML 5 adoption and no browser but
IE is really courting the enterprise (the largest group of XForms
adopters), I
personally doubt XForms could find a home inside a main stream
browser.
Especially when most browsers are trying to get as lean and mean as
possible
to get on mobile devices (the fastest growing platform in the market).

--Aaron


On Aug 21, 5:52 pm, KevinC <[hidden email]> wrote:

> On Jul 13, 8:46 am, Philipp Wagner <[hidden email]> wrote:
>
> > Hi!
>
> Thanks for all you have done.
>
> > 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
>
> I agree, but for a different reason.  Browsers should support it 'out
> of the box.'  While this isn't a realistic expectation for IE, there
> are other browsers out there that a lot of people use.  E.g. Opera,
> Chrome.  These seem to have more reasonable corporate backing.  Have
> you been in contact w/ the respective browsers?  Adding XForms as a
> routine item (at least in non-M$ browsers) will spur the adoption of
> XForms (or at least break down one objection for use).
>
> I also agree with your comment about HTML5.  XForms transformation to/
> from HTML5 forms will likely be needed.  This is unfortunate, but it
> isn't likely that w3c will make changes to make life easier.  With
> architectures like XRX for complex domains (e.g. healthcare,
> biomedical research) the need for the model + constraints (which can
> be discovered at run time) is critical.
>
>
>
>
>
>
>
> > Ideas, thoughts?
>
> > Philipp
>
> > 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/thr...
> > [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 athttp://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_...
> > [4]http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
> > [5]http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctype...

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

FraserHore-2
Although browser makers are unwilling to provide native support for xforms, they have put a huge amount of effort into fast javascript engines.  This makes a javascript-based xforms processor a very attractive option.  Is there any way to take the learning from the Mozilla plugin and apply it to the development of a javascript xforms processor?  Ubiquity xforms was making great progress but seems to have stopped development, could it be revived?  Alternatively, the xquery-in-the-browser project is really interesting and an xforms processor written in xquery would be very cool and possibly easier to build and maintain.  In either case the xforms processor could be run on the server, in the browser, or both.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

Phil Reid
see: http://sourceforge.net/projects/xsltforms/

Regards
Phil

On 19/10/2011 4:10 PM, Fraser wrote:
> Although browser makers are unwilling to provide native support for xforms, they have put a huge amount of effort into fast javascript engines.  This makes a javascript-based xforms processor a very attractive option.  Is there any way to take the learning from the Mozilla plugin and apply it to the development of a javascript xforms processor?  Ubiquity xforms was making great progress but seems to have stopped development, could it be revived?  Alternatively, the xquery-in-the-browser project is really interesting and an xforms processor written in xquery would be very cool and possibly easier to build and maintain.  In either case the xforms processor could be run on the server, in the browser, or both.
> _______________________________________________
> dev-tech-xforms mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-xforms
>
>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Future of Mozilla XForms

mozillaxforms
In reply to this post by FraserHore-2
Orbeon is also JavaScript based, as is FormFaces and AJAXForms.  You
might want to try the w3.org Xforms newsgroup to see if any other
processors fit your needs (sorry, I haven't really been keeping up
with new things in this space).  While Mozilla XForms would offer a
start on that path, it is a well trod path with other, more recent,
implementations available in open source that would probably be a
better place to begin.

--Aaron

On Oct 19, 4:00 am, Phil Reid <[hidden email]> wrote:

> see:http://sourceforge.net/projects/xsltforms/
>
> Regards
> Phil
>
> On 19/10/2011 4:10 PM, Fraser wrote:
>
>
>
>
>
>
>
> > Although browser makers are unwilling to provide native support for xforms, they have put a huge amount of effort into fast javascript engines.  This makes a javascript-based xforms processor a very attractive option.  Is there any way to take the learning from the Mozilla plugin and apply it to the development of a javascript xforms processor?  Ubiquity xforms was making great progress but seems to have stopped development, could it be revived?  Alternatively, the xquery-in-the-browser project is really interesting and an xforms processor written in xquery would be very cool and possibly easier to build and maintain.  In either case the xforms processor could be run on the server, in the browser, or both.
> > _______________________________________________
> > dev-tech-xforms mailing list
> > [hidden email]
> >https://lists.mozilla.org/listinfo/dev-tech-xforms

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Loading...