Burak and I touched on this subject in posts during this past week related to my question on an Oracle RPC server for Qooxdoo.
In that discussion, I mentioned that I think SOAP is more appropriate where two server systems are exchanging data in order to extend the usefulness of existing server systems. In the context of a client- server interaction, especially where Javascript is involved as in Qooxdoo, I also think the JSONRPC protocol is more appropriate. Where you have control of both the client and server environments, JSONRPC may be optimal. Outside of Javascript and Qooxdoo, SOAP probably has a stronger use case. In all I've read on this list, it appears that JSONRPC is the prevalent method of performing RPC communications among those using Qooxdoo. Of course, if an existing SOAP service (unrelated to Qooxdoo) exists on a server, Qooxdoo *should* have the capability to query those types of services in order to maximize the usefulness of the Qooxdoo client framework. Since I've not looked for those types of features, I don't know if they exist in the production framework. If Burak's contribution provides missing client-side SOAP capability to use SOAP services outside of Qooxdoo, this would be a significant benefit, maybe more so than the SOAP server component itself. HTH, Gene On Wed, 2009-06-24 at 16:52 +0200, Andreas Junghans wrote: > Hi Burak, > > Am 24.06.2009 um 14:10 schrieb Burak Arslan: > > > Andreas Ecker wrote: > >> qooxdoo/Python people speak up! ;-) > >> > >> > > > > i keep repeating this but here it is again: i got a soap-rpc server in > > the soap contrib. > > The problem is that SOAP is (IMHO) a bad choice for RPC calls from > JavaScript. In fact, I think it's a bad choice for almost _any_ RPC > environment, but that's another story :-P (Here's a funny, sad, and > true piece about its history - more than two years old, but still > valid: > http://72.249.21.88/nonintersecting/?year=2006&monthnum=11&day=15&name=the-s-stands-for-simple&page=) > > There's a lot of processing involved for even the simplest of calls. > And there's just sooo much that can go wrong. Just try passing nested > arrays or anything remotely complex, and more often than not the whole > thing breaks down. > > Personally, I'm trying to stay away from SOAP in the browser as far as > I can. It's bloated, fragile, and slow. The only usecase I see is for > calling an existing SOAP service that you cannot wrap in or proxy with > JSON-RPC. I guess I'm not alone with my assessment, which might > explain why your SOAP implementation doesn't elicit a lot of feedback. > > Disclaimer: I'm not in any way criticizing your implementation (which > I haven't looked at). I'm talking about the protocol itself and its > usefulness (or not) for browser-based applications. > > Regards, > > Andreas J. > > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
