A question for you. Is SOAP a request language or a stream language? The request below is in request format. You send a request, and get an answer back.
That is NOT the way opensrs operates. The OpenSRS system is set up so that you open the connection and send a stream of commands to the server. This means, that you should be able to make several requests during the same session. For example: login lookup mydomain.com lookup mydomain.ca lookup mydomain.net exit. Or for that matter, login register thisdomain.com register thatdomain.com register theotherdomain.com transfer thisotherdomain.ca lookup thisdomain.com get_info something.ca exit. I do not know how much streaming the client uses. I do know that it is possible for the server to operate this way, because of the way it is set up. If SOAP contains some means to handle things in this way, then it is compatible with the existing system. I am all for a providing the means to interface to OpenSRS through as many languages as possible. I do not think that it is appropriate to change the way that the communication operates to do so. There are really good reasons for maintaining a protocol that allows you to stream requests. Those reasons do not particularly apply to smaller resellers, particularly those who do not want to use perl... With this said, there is no reason at all that opensrs should not cater to both worlds. They can easily build a system that translates a single transaction request into a streaming mechanism. --------------------------------------------------------------------- Tim Woodcock [EMAIL PROTECTED] BareMetal.com Inc. http://baremetal.com/ Software Development Team --------------------------------------------------------------------- Message received 2003-10-27 from 'Chris Andrews': > Tim Woodcock wrote: > > > "SOAP" and simple do not belong together in the same sentence. > > > > If you want simple, XML is ok. But SOAP is a way of adding software > > context on top of data. That is not simplicity. > > Yes, the SOAP on-the-wire protocols are complicated, especially when you > start adding WSDL into it. It's not fast, either. > > But - you don't have to look at the wire protocol to use it, because > pretty much every combination of platform and language has a SOAP client > library available. A reasonable library should make accessing a SOAP API > simple - as an example, it's more than possible to write SOAP client > one-liners with Perl and SOAP::Lite ... yes, you can leave the 'all Perl > looks like a one liner' gags right there :) > > Seriously though, this *is* simple: > > use SOAP::Lite; > print SOAP::Lite > -> uri('http://www.soaplite.com/Temperatures') > -> proxy('http://services.soaplite.com/temper.cgi') > -> f2c(32) > -> result; > > (from http://www.soaplite.com) > > That's a trivial example though, and any OpenSRS SOAP API would > necessarily have more elaborate methods than 'f2c', but as the library > should take care of type conversions and so on, using the methods should > be no less simple. > > This isn't to say, however, that SOAP is the only way forward. All I'd > like to see is simply OpenSRS accepting that what's needed is an API, > not a set of client CGI scripts with a reasonable but underdocumented > API buried underneath. Sure, the methods themselves are pretty well > documented, but as far as I can see, the documentation for the transport > is XML_Client.pm and friends. > > Perhaps a reasonable first step would be to document the entire protocol > in a language-neutral way, and then there'd be no excuse for those who > don't speak Perl not to build a client for the current API with whatever > system they choose. > > > Chris. >
