Much of the time the premise seems to be "well, I can't do the current API on my platform" -- and the available implementations (in PHP and as an Active-X component) seem to suggest otherwise.
As the developer of the PHP client, I'll throw in a few comments here.
Developing the PHP client was not really that hard, since initially I basically "translated" the Perl code to PHP. Since then, I've made improvements to take advantage of things PHP does better/different than Perl, and also because I grok PHP better than Perl.
Notwithstanding the above, the encryption portion of the OpenSRS protocol was a major pain in the ass. It may use standard encryption protocols (DES, Blowfish, CBC, etc.), but it the implementation (Crypt::CBC) is *not* standard in anyway. This caused much gnashing of teeth and tearing of hair, and eventually I had to "translate" Crypt::CBC into PHP before I could even look at the OpenSRS code. This wasn't easy, and I would happily agree that it makes porting the OpenSRS client to other languages/platforms non-trival.
SOAP has a lot of overhead, sure, compared to the XCP/TPP XML that OpenSRS developed. Howver, how many SOAP-to-{your-favourite-language} classes already exist? If OpenSRS had used SOAP, they wouldn't need to write one line of XCP-to-Perl code, and I wouldn't have need to write any XCP-to-PHP code.
Using standards has three main benefits, in my opinion. First, it lowers the barrier to entry for your system. Everyone who understands the standards you use can almost immediately comprehend your system and, if they choose to, implement it in another language or on another platform. That has the second benefit of opening up your system to a much larger audience of users. And third, it "offloads" some of the development of your system onto the fine people who build the {standard}-to-{language} modules. You simply need to string those modules together and focus on processing the data, instead of worrying about the intermediary stages. That should (theoretically) make your development cycle faster.
So ... I'm all for OpenSRS switching to a SOAP/SSL solution.
- Colin
