> SOAP's not tied to a single transport. When run over HTTP, as is most > common, you make one request, and get one reply. You can run SOAP over a > bare TCP connection though, and in that case you're free to make as many > requests as you like over that connection.
So it is not the protocol that you object to. It is the means of communication. If opensrs implemented a means toB send a web request to get a registration done, you'd be happy. SOAP has nothing to do with it. It is just a way of making it easier to channel the request for any language. By the way, this is the way that registrars communicate with CIRA. It may be just implementation details, but it is easier to talk to OpenSRS than CIRA. One of the problems with CIRA is that it is much slower than most opensrs requests, for example. > Having said that, I can't imagine that it would be wise to use anything > but SOAP over HTTP, because that's the best-supported way of using it. Heh. That'd show them web browser developers what for. No more HTML! :-) > I think the OpenSRS API is pretty close to the SOAP over HTTP model - > you make a request for an authentication cookie, then make any number of > requests using that cookie, then you request that cookie be destroyed. Opensrs provides a cookie mechanism, but the API does not use it in the general case. You log in, you stream 1 or more requests, and you exit. > You're only authenticating once for all the requests you make (within > the validity of a single cookie), although you are using a separate TCP > connection for each one - but that's a *tiny* overhead compared to the > whole XML and SOAP shebang. No. You are authenticating with every request you make. The cookie is a means of authentication. It just isn't your userid and password. The authentication overhead is as much or more on the server side. > As for authenticating access to the SOAP service itself, there's all > manner of different ways - with HTTP, ordinary Basic authentication is > possible, with SSL there's client certificates, and there are also > standards like XML Signature and XML Encryption. You don't want to go there. The existing mechanism is authenticate, stream requests, exit. SOAP cannot compete with that simplicity. Now... If we found a way (and I believe there is one) to provide multi-platform support for streaming HTTP, and used it to channel SOAP requests... You'd have no need for basic auth, etc... > .NET people - what authentication methods are available/usual for SOAP > services on that platform? So you provide a C library or something that someone can incorporate into M$.net. The problem is NOT the protocol, it is just that it is not implemented everywhere. This is the reason that perl and other new-age languages like ruby, python, etc are so adaptable is because they are able to work off the same C library. Before we go further: There is NO reason why OpenSRS should/could not provide an interfacing mechanism that allows a .net client to connect using SOAP, through a translator interface. THAT is what you should be asking for. It should be easy to do, and it does not require changes to the back end, nor does it require that comprimizes be made to the flexibility of the existing system. > > 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... > > I'm not sure I follow you here. Could you expand on this? If you want to set up a bulk registration interface, you can open a connection, stream all your requests, get all your answers back, and close the connection. You authenticate once, issue 100+ requests, and exit. It is so much more efficient. Then, if you put SSL into the picture, you make the SSL connection (large overhead) once, login, once, and stream. Every second counts, as does every authentication request. Remember that on the server side, YOU'RE clients are not the only one that is making the connection. It is you, and every other resellers' client's dog.
