L.C. Thank you for your comments. The "home grown" nature of OpenSRS does have its quirks. We'll keep these in mind for further changes to the API, but we do also have to be careful to maintain full backwards compatability with previous versions of our code, which could make language/platform independence more difficult.
Charles Daminato TUCOWS Product Manager [EMAIL PROTECTED] On 9 Dec 2001, L.C. wrote: > > I just finished reading the OpenSRS Protocol Message Format and the > XCP specs (the parts showing how to encode the requests in XML and > how to connect to server and so on) and I have a few comments. > > It seems to me (I might be wrong) that the OpenSRS engineers have > spent a good deal of effort to create parallel versions of the > XML-RPC and SSL protocols. > > The code is further complicated due to combining of the presentation > and application layers. For instance, the connection preamble (client > validation, encryption set-up) could have been done via an SSL module. > Using client certificates would alleviate the need for the reseller > "cookie" and secret passwords. All these details are irrelevant to the > function the server performs and should be left to a lower layer. > > If known standards were used then a big obstacle for implementing the > client in other languages would be removed, because there is a high > chance that they have XML-RPC already, and if the (Open)SSL library > doesn't have a wrapper in that language yet, external programs can be > used as "filters" (pipes) to achieve the same job. Let alone there > would be less logic to implement in the client so it would be faster > to develop and easier to manage. > > I would be very happy if a later major (minor? I don't want to push > it :) ) release would explore these options. > > -- > L.C. > Network Admin @ InfoStreet > >
