My personal opinion is that SOAP was not a good technology for remote procedure call, because they tried to make the data type schema too open-ended. I prefer things like JSON and REST, *because* they are limited in scope. I think that they give more robust interoperation than SOAP, because the SOAP implementations are too complex.
I prefer XML-RPC over SOAP for the same reason. I am not sure now though what the best replacement technology is. I like the idea of JSON RPC, but it does not seem to have caught on so far with many services. On Thu, Nov 4, 2010 at 11:41 AM, Ono Keiji <[email protected]> wrote: > This is the exact reason why, i think. :^) > So i would like to hear your opinion. > Do you think SOAP keep going to be important I/F around WEB ? > In fact, there are few people to use soap i/f around me. > > ono > > > Quoting Ono Keiji <[email protected]>: > > Thank you Henry, >> >> I wonder SOAP is not important I/F any more around WEB scene? >> If it would be deprecated I/F near future around WEB scene, i would be >> sit and keep watch it. But if it would not be, it would might got worth >> to try. >> As a matter of fact, why the team has backed off from it ? >> >> Best, >> >> ono >> >> >> Quoting Henry Minsky <[email protected]>: >> >> Ono-san, unfortunately there's no scheduled work on SOAP being planned, >>> but >>> if >>> you have ideas on how to update the support we could look at integrating >>> it. >>> Ideally >>> there would be some supported 3rd party SOAP javascript library that we >>> might be >>> able to use, that would run in both DHTML and SWF10. >>> >>> On Wed, Nov 3, 2010 at 10:38 PM, Ono Keiji <[email protected]> wrote: >>> >>> Hi, >>>> >>>> If any change of progressing this, i would appreciate if i could hear >>>> about it. >>>> And also work together on it. >>>> >>>> Best, >>>> >>>> Ono >>>> >>>> >>>> Quoting Henry Minsky <[email protected]>: >>>> >>>> During our latest bug scrub, the OpenLaszlo team had to make a decision >>>> >>>>> about how to prioritize SOAP bugs. >>>>> We realized that we don't have the resources to continue maintaining >>>>> the >>>>> existing SOAP functionality, >>>>> along with the large number of high priority platform tasks that we are >>>>> working on. >>>>> >>>>> If there are people in the community relying on SOAP support, this >>>>> might >>>>> be >>>>> an opportunity to get together >>>>> and work on a new version of an API. >>>>> >>>>> >>>>> The way the SOAP package works currently is by passing a SOAP envelope >>>>> to >>>>> the LPS server, where an Apache library in Java is used as a proxy to >>>>> perform the SOAP request. But given the power of today's Flash 10 and >>>>> DHTML >>>>> runtime environments, I think it might be possible to implement the >>>>> SOAP >>>>> mechanism completely in LZX/javascript on the client. >>>>> >>>>> >>>>> The LPS server (or something compatible with the data proxy protocol) >>>>> could >>>>> still be used to prox underlying XML data requests at the transport >>>>> layer, >>>>> if that were needed to bypass browser security limitations. But it >>>>> would >>>>> simplify things considerably to implement the SOAP protocol entirely >>>>> in >>>>> LZX. >>>>> >>>>> I have read that Flash 10 has a SOAP RPC library (though I have not >>>>> tried >>>>> it), and there may be others available written in Javascript for DHTML >>>>> which would make a good base for a new SOAP package for OpenLaszlo. >>>>> >>>>> It does not look like we're going to be fixing any of the outstanding >>>>> SOAP >>>>> bugs at this point, so users depending on >>>>> this feature should begin to make other plans. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Henry Minsky >>>>> Software Architect >>>>> [email protected] >>>>> >>>>> >>>>> >>>> >>>> -- >>>> ------------------------------------------ >>>> Ono Keiji >>>> [email protected] >>>> 1-45-11 Mizue Edogawa Tokyo JP >>>> TEL 03(3676)6599 >>>> URL http://www.net8.co.jp >>>> ------------------------------------------ >>>> >>>> >>>> >>>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >>> >>> >> >> >> -- >> ------------------------------------------ >> Ono Keiji >> [email protected] >> 1-45-11 Mizue Edogawa Tokyo JP >> TEL 03(3676)6599 >> URL http://www.net8.co.jp >> ------------------------------------------ >> > > > > -- > ------------------------------------------ > Ono Keiji > [email protected] > 1-45-11 Mizue Edogawa Tokyo JP > TEL 03(3676)6599 > URL http://www.net8.co.jp > ------------------------------------------ > > -- Henry Minsky Software Architect [email protected]
