This is going to be very inflamatory, but there are a few things I have to say.
... "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. It would be fairly easy for tucows to add SSL to the existing system. SSLeay can be used to do this. I am not opposed to seeing SSL in the registration system, possibly as an optional access method... However, you'll find this slows domain registrations down. The current mechanism is designed for speed. Since most of the information that runs in plain text is available in plain text anyway via whois, who cares? ... Now.. SOAP. Somebody on this list told me a while ago that EPP was SOAP. Silly me, I believed them. Epp is not SOAP. EPP is an XML protocol, very much like the XCP protocol that OpenSRS currently uses. The client sends XML commands in a stream, and the server reads and decodes the commands. This mechanism is simple. With soap, you can probably do the same streaming, but the means of decoding the data is encoded in the data stream. IMHO, this is dangerous. It definetly does not qualify as simple. It requires an additional layer of complexity on both sides. Frankly, I see no point. I believe what you actually want is a standard library for translating to/from the XML or, from the other point of view, to/from a native structure. But since this is what you already have... --------------------------------------------------------------------- Tim Woodcock [EMAIL PROTECTED] BareMetal.com Inc. http://baremetal.com/ Software Development Team --------------------------------------------------------------------- Message received 2003-10-27 from 'Fagyal, Csongor': > Adam Selene wrote: > > >SOAP over SSL would be the simplest and most standard, > >I can't believe how long this request has been left unanswered. > >TuCows, > > > Yep. Actually I found this more important than the CGIs (brrr!) - Tucows > should have started with a standard interface _first_, and do the CGIs > later (or not at all... but that is my personal opinion, and not a very > marketing-friendly one :-)). > > > fire your Perl programmers and hire someone with > >clue. > > > > > You are bad :-) "When in doubt, blame the programmer." I guess they > simply do what they are told, and as fast as much they are paid. > > However, I also think it should be fairly easy to take the current > server side processing modules and glue them to SOAP. It's just some > action mapping and that's all... Upload it to the test environment, the > community tests it, and nobody gets hurt ;-). > > - Cs. >
