Our implementation of SOAP is incomplete, very buggy, and not really useful on the Web. I think we should remove it and save us some download size.

I agree completely. What about XMLRPC, which seems similarly buggy?

Should probably propose this to mozilla.dev.platform

Someone recently offered up a pretty complete SOAP impl, with an XMLHttpRequest programming model, for inclusion in Firefox. I'll try to dig up the contact and point them at the thread in m.d.platform if someone drops a link here.

There are actually 3 parts in extensions/webservices: XML Schema Parser, SOAP and WSDL. The only thing I care about is the schema parser for XForms (which I have been fixing/cleaning up), but I can probably separate that code out into its own extension and compile it for XForms. I doubt we have much SOAP/WSDL users out there (the only one I know of is reporter). And if SOAP/WSDL ever comes back in fashion (fast XML structure parsing/js creation, which perhaps E4X will/does provide), we can rethink it.

btw, is this trunk only or 1.8 branch also?

It should probably be trunk only since we decided against API changes for FF2.

Yeah, trunk-only would give us a long lead-in period to gauge developer impact.

I hope this doesn't come through, or at least, code that is removed from the FF distribution be repackaged as a "standard" extension. Since pre-Mozilla 1.0 days we have been using XML-RPC and now Webservices and SOAP to construct client applications against J2EE servers. With hundreds of thousands of XUL/JS/XPCOM lines of code, we have definitely taken to Mozilla as a _platform_ and despite the bugs we have found we believe it an excellent (read lean, portable, elegant) choice for client applications. To remove its SOAP/XML-RPC capabilities is to tear apart the bridge between Mozilla/FF the Client and whatever its server may be. While the browser may not care for WS, the XUL/XPCOM platform needs it fundamentally. Mike Shaver mentions in comment 3 of a possible drop in replacement. I am very interested in this. While we don't have the capacity to develop a new SOAP infrastructure, we might be of help in integrating a new mechanism.

An interesting value of our SOAP implementation was the security model that allowed a cross site communication so page from A.com to interact via Web Services with B.com if B.com has the xml file ( web-script-access . xml ). This is the same thing Macromedia Flash does. So if we go in this direction would be interesting to consider: * Keep a safe controlled story for cross site access. For example XMLHTTP, XMLRPC ( and future XML / DOM-based rpc solutions should all work through the same security rules ). Google is doing good job in workaround to that, via their solution that dumps scripts in the tree using <script />. References: http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html

Since SOAP support is currently still in the trunk, I wonder what is the status of the SOAP implementation in Mozilla. Is it useful to submit new bugs concerning the SOAP implementation? We're using the SOAP support in Mozilla to build XUL based user-applications that interface with a server back-end. I would be disappointed to see SOAP support removed.

I would strongly argue for keeping the SOAP interface. Its a very useful API to have built into the mozilla platform. Additionally, numerous Mozilla app books show usage examples and there are a number of existing extensions that rely on its existence (including mine). Pulling the rug out from under people using this API because of a few bugs seems cruel and unnecessary.

It's not just a few bugs. It's a _lot_ of bugs, combined with lack of security review and no one maintaining the code. That last part is key. If someone were maintaining the code, this discussion would not be happening.

This should be dropped without an owner, a lot of bugfixes, and a security review or three. It can be revived at the risk of users, and at the cost of a separate download or bundling deal, via an extension. This is a no-brainer. We removed MNG for less. /be

I would strongly argue for keeping the SOAP interface, too. I'm developing a lot of applications with firefox and specially with thunderbird that uses SOAP API, this applications in many times replace Outlook or give the chance to communicate to applications like Sugarcrm, etc. from another platforms like linux, macs, etc. Where there is not outlook support. While microsoft and many developers implement and use this as a key point, we are thinking on drop it. Well I really think this is not a good idea..

If you're willing to maintain it, great. If not, whom are you suggesting for the job?

After 15 months, discussion shows no indication of ownership, fixed security bugs, or evidence that our implementation is sufficient to communicate with Microsoft WCF (looks like extensions are including Apache Axis to do this). I claim enough is enough.

I'm not the right reviewer for this. I would suggest peterv.

Comment on attachment 272582 [details] [diff] [review] disable MOZ_WEBSERVICES by default Switching review to peterv.

Comment on attachment 272582 [details] [diff] [review] disable MOZ_WEBSERVICES by default Shouldn't this also change the documentation in configure.in from --disable-webservices to --enable-webservices?

I guess for XForms we can bring in what we need for schema support into our extension or the schema validator extension as Doron noted in comment #4. But I hope that the code that we need can be easily ported to use frozen API's since that is what is going to be required of extensions for FF3.

I honestly feel disabling SOAP support (even temporarily) in the mozilla platform is a huge mistake. As someone already stated in comment #8: "To remove its SOAP/XML-RPC capabilities is to tear apart the bridge between Mozilla/FF the Client and whatever its server may be. While the browser may not care for WS, the XUL/XPCOM platform needs it fundamentally." Not everyone has the luxury (or control) of coverting all their remote SOAP endpoints to the XMLHttpRequest-based model. So now, any XUL applications or Firefox extensions that rely on this very important interface to communicate with existing SOAP interfaces will be S.O.L. What's even more alarming to me is that the good people at Mozilla are considering dropping such a key client-server communications support feature without so much as a cursory poll of the many thousands of moz developers out there who may be depending on this key feature. Not everyone who cares about SOAP support in mozilla is on this bug's CC list or even aware that this bug (and its proposed change) even exists. So this will hit developers by surprise, and will likely appear only as a footnote in the FF3.0 release notes. The result will be many broken extensions and XUL applications, with developers being left in the lurch and faced with a huge re-development effort they had not planned on, with no recommended migration path. Is this the proper way to deprecate such an important mozilla API?

(In reply to comment #22) > I honestly feel disabling SOAP support (even temporarily) in the mozilla > platform is a huge mistake. As someone already stated in comment #8: > > "To remove its SOAP/XML-RPC capabilities is to tear apart the bridge between > Mozilla/FF the Client and whatever its server may be. While the browser may > not care for WS, the XUL/XPCOM platform needs it fundamentally." Says some of its users. Not all. Carry your own weight. > Not everyone has the luxury (or control) of coverting all their remote SOAP > endpoints to the XMLHttpRequest-based model. So now, any XUL applications or > Firefox extensions that rely on this very important interface to communicate > with existing SOAP interfaces will be S.O.L. No, carry your own weight. No free lunch. > What's even more alarming to me is that the good people at Mozilla are > considering dropping such a key client-server communications support feature > without so much as a cursory poll of the many thousands of moz developers out > there who may be depending on this key feature. Polls mean nothing in open source. Actually standing up and owning the code, sweating the bugs including full-remote-exploit security vulnerabilities, is what counts. In that light, your soap-boxing here is not helpful. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html (anyone new to bugzilla, or just anyone who thinks this doesn't apply to their special-pleading). > Not everyone who cares about > SOAP support in mozilla is on this bug's CC list or even aware that this bug > (and its proposed change) even exists. So this will hit developers by > surprise, and will likely appear only as a footnote in the FF3.0 release notes. Robert Sayre has posted to mozilla.dev.platform, which those developers should be reading. Adding the relnote keyword. > The result will be many broken extensions and XUL applications, with > developers being left in the lurch and faced with a huge re-development effort > they had not planned on, with no recommended migration path. The source is not being cvs removed. You can host it in a binary component that you distribute. Carry your own weight. But really, it's buggy and out of date. There are better solutions. Sayrer just mentioned http://www.ibm.com/developerworks/webservices/library/ws-wsajax/ to me over IRC. So stop demanding a free lunch when the sandwich is green with mold already! (Marge: "Homer, are you still eating that sandwich?"; Homer, to the moldy sandwich: "Oh, I can't stay mad at you!") > Is this the proper way to deprecate such an important mozilla API? It's not an important Mozilla API or the code wouldn't be unowned, buggy, downrev, and about to be removed from default builds. Get real! /be

"Two more feet and I can fit it in the fridge!" /be

Checked in on trunk. Firefox Z: 13.36 -> 13.06 Zdiff:-315744 Seamonkey Z:20.69 -> 20.23 Zdiff:-480148 (+0/-480148)

Comment on attachment 272903 [details] [diff] [review] updated removed-files.in r=me, but please also remove these from packages-static (both unix and windows).

This broke all my builds because the schema-validation extension is in MOZ_EXTENSIONS_ALL, depends on webservices, and didn't get the sort of code that xforms has in configure.in...

(In reply to comment #28) > This broke all my builds because the schema-validation extension is in > MOZ_EXTENSIONS_ALL, depends on webservices, and didn't get the sort of code > that xforms has in configure.in... > Fixed in bug 388920.

This also caused me a bit of heartache, because I was using the interfaceinfo part of webservices. How can I get just that part back?

Perhaps that code should move out of webservices into an extension of its own?

I'd support that, from extensions/webservices/interfaceinfo/src to extensions/interfaceinfo. Three questions. (1) Would it be better for me to submit a patch (considering I don't have cvs check-in access), or should we get a cvs move by someone with commit privileges, with the MODULE and LIBRARY_NAME values modified properly? (2) Should we have this on by default? It was before, but that's a poor excuse. (3) Should this go into a new bug, requesting blocking1.9 for the regression?

New bug no matter what.

Just a note for anyone who might read this later, we (XForms) are copying the schema parser code into the schema-validation extension and renaming the interfaces/services so as to not cause a conflict should someone decide to build and distribute webservices in the future.

Bug 392004 filed for restoring interfaceinfo, with patch submitted and seeking reviews. Aaron, your input would be welcome so as to avoid conflicts.

Are there any new plans to reintegrate SOAP? Or are there any alternatives to SOAP and WSDL?

There are no plans to re-integrate this as a client feature, but you can use SOAP from webscript through an AJAX wrapper library, such as that described here: http://www.ibm.com/developerworks/webservices/library/ws-wsajax/

The AJAX wrapper library seems to be suitable for websites, but what about extensions which communicate with different hosts? Since the SOAP support has been dropped, what is the alternative solution for extension developers? Is it a different SOAP libary or is XML-RPC the suggested way? By the way will XML-RPC also removed as suggested in comment #1?

Does the AJAX wrapper library not work in your extension? It should, and should have privileges sufficient to contact arbitrary hosts even without their explicit cross-site consent. If it does not, please file a new bug with test case and reference it here.

No, it's not working in chrome in FF2.00.12, FF3.0b3 works fine. The error message is: "WS.Call.InvokeHandlers.bind is not a function" Maybe this is the same problem as described in https://bugzilla.mozilla.org/show_bug.cgi?id=300079

Yeah, probably is, but SOAP support is still there in FF2, so if the ws-ajax solution works on trunk, I think we're fine. Thanks for the report!