Last Comment Bug 332174 - Drop SOAP support
: Drop SOAP support
Status: RESOLVED FIXED
: relnote
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Robert Sayre
: Hixie (not reading bugmail)
Mentors:
Depends on: 388920 392004
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-29 18:09 PST by Hixie (not reading bugmail)
Modified: 2008-08-11 04:30 PDT (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
disable MOZ_WEBSERVICES by default (647 bytes, patch)
2007-07-16 20:02 PDT, Robert Sayre
no flags Details | Diff | Review
flip ENABLE/DISABLE (1.61 KB, patch)
2007-07-17 09:28 PDT, Robert Sayre
peterv: review+
brendan: superreview+
Details | Diff | Review
updated removed-files.in (2.36 KB, patch)
2007-07-18 20:08 PDT, Robert Sayre
gavin.sharp: review+
Details | Diff | Review

Description Hixie (not reading bugmail) 2006-03-29 18:09:51 PST
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.
Comment 1 Benjamin Smedberg [:bsmedberg] 2006-03-30 10:51:54 PST
I agree completely. What about XMLRPC, which seems similarly buggy?
Comment 2 Benjamin Smedberg [:bsmedberg] 2006-03-30 10:53:04 PST
Should probably propose this to mozilla.dev.platform
Comment 3 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-03-30 11:01:19 PST
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.
Comment 4 Doron Rosenberg (IBM) 2006-03-30 11:26:07 PST
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.
Comment 5 Doron Rosenberg (IBM) 2006-03-30 11:27:46 PST
btw, is this trunk only or 1.8 branch also?
Comment 6 Darin Fisher 2006-03-30 11:41:54 PST
It should probably be trunk only since we decided against API changes for FF2.
Comment 7 Hixie (not reading bugmail) 2006-03-30 13:31:55 PST
Yeah, trunk-only would give us a long lead-in period to gauge developer impact.
Comment 8 C. Daniel Mojoli B. 2006-07-12 12:25:52 PDT
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.
Comment 9 /\/\arcio Galli 2006-12-12 13:46:33 PST
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

Comment 10 Martijn de Vries 2007-01-11 03:29:24 PST
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.
Comment 11 carglue a t ya hoo do tcom 2007-01-26 14:45:36 PST
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.
Comment 12 Boris Zbarsky [:bz] 2007-01-26 14:58:41 PST
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.
Comment 13 Brendan Eich [:brendan] 2007-01-26 16:26:57 PST
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
Comment 14 Lyle Arnot 2007-06-05 10:26:30 PDT
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..
Comment 15 Boris Zbarsky [:bz] 2007-06-05 10:55:45 PDT
If you're willing to maintain it, great.  If not, whom are you suggesting for the job?
Comment 16 Robert Sayre 2007-07-16 20:02:47 PDT
Created attachment 272582 [details] [diff] [review]
disable MOZ_WEBSERVICES by default

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.
Comment 17 Boris Zbarsky [:bz] 2007-07-16 20:42:24 PDT
I'm not the right reviewer for this.  I would suggest peterv.
Comment 18 Robert Sayre 2007-07-16 20:53:42 PDT
Comment on attachment 272582 [details] [diff] [review]
disable MOZ_WEBSERVICES by default

Switching review to peterv.
Comment 19 Peter Van der Beken [:peterv] 2007-07-17 08:06:00 PDT
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?
Comment 20 Robert Sayre 2007-07-17 09:28:53 PDT
Created attachment 272658 [details] [diff] [review]
flip ENABLE/DISABLE
Comment 21 aaronr 2007-07-17 09:56:11 PDT
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.
Comment 22 carglue a t ya hoo do tcom 2007-07-17 10:47:06 PDT
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?
Comment 23 Brendan Eich [:brendan] 2007-07-17 11:41:03 PDT
(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
Comment 24 Brendan Eich [:brendan] 2007-07-17 12:03:40 PDT
"Two more feet and I can fit it in the fridge!"

/be
Comment 25 Robert Sayre 2007-07-18 14:14:31 PDT
Checked in on trunk.

Firefox
Z: 13.36 -> 13.06
Zdiff:-315744

Seamonkey
Z:20.69 -> 20.23
Zdiff:-480148 (+0/-480148)
Comment 26 Robert Sayre 2007-07-18 20:08:09 PDT
Created attachment 272903 [details] [diff] [review]
updated removed-files.in
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-19 08:32:01 PDT
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).
Comment 28 Boris Zbarsky [:bz] 2007-07-19 23:03:31 PDT
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...
Comment 29 Robert Sayre 2007-07-20 12:46:03 PDT
(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.
Comment 30 Alex Vincent [:WeirdAl] 2007-08-12 21:52:57 PDT
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?
Comment 31 Boris Zbarsky [:bz] 2007-08-12 22:06:40 PDT
Perhaps that code should move out of webservices into an extension of its own?
Comment 32 Alex Vincent [:WeirdAl] 2007-08-12 22:35:34 PDT
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?
Comment 33 Boris Zbarsky [:bz] 2007-08-12 22:45:54 PDT
New bug no matter what.
Comment 34 aaronr 2007-08-13 09:44:16 PDT
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.
Comment 35 Alex Vincent [:WeirdAl] 2007-08-14 20:31:04 PDT
Bug 392004 filed for restoring interfaceinfo, with patch submitted and seeking reviews.  Aaron, your input would be welcome so as to avoid conflicts.
Comment 36 Karsten 2008-02-24 08:25:42 PST
Are there any new plans to reintegrate SOAP? Or are there any alternatives to SOAP and WSDL?
Comment 37 Benjamin Smedberg [:bsmedberg] 2008-02-24 08:32:50 PST
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/
Comment 38 Karsten 2008-02-26 01:10:46 PST
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?
Comment 39 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-26 05:06:47 PST
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.
Comment 40 Karsten 2008-02-28 01:00:44 PST
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
Comment 41 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-02-28 03:55:15 PST
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!

Note You need to log in before you can comment on or make changes to this bug.