I've seen a lot of discussion lately on this list about upcoming API
changes and comments on said changes. Also a recent comment from "Niel
H" regarding HTTP POST access to the server, which would give access to
a much wider range of clients than just stuff written in Perl. Colin
Viebrock made some very interesting (IMHO) comments about XML a while
back, regarding the proposed changes Charles made on the list:
Colin Viebrock wrote:
>
> All of those changes look like Good Things.
>
> Infact, they look pretty darn close to XML structures. Had any thought
> gone into using XML as the "language" to pass commands and data to the
> server? Something like:
>
> <opensrs>
> <action>modify</action>
> <object>domain</object>
> <cookie>123456789:998877</cookie>
> <attributes>
> <contact_info which="admin">
> <first_name>John</first_name>
> <last_name>Smith</last_name>
> ...
> </contact_info>
> <contact_info which="billing" sameas="admin"></contact_info>
> <contact_info which="tech" sameas="admin"></contact_info>
> <contact_info which="owner" sameas="admin"></contact_info>
> </attributes>
> </opensrs>
>
> I'm no XML expert, so no comments on the format of the above please.
>
> However, using an open (and extensible) standard like XML would be fitting
> with the goals of the OpenSRS ... and would also make the API for
> communicating
> with the server more portable to other client platforms (i.e. non-Perl).
>
> Thoughts?
My thoughts, like at least a few others I've seen on the list, are that
this is an incredibly good idea.
Like at least a couple others who've chimed in on the list, I am not by
nature a Perl hacker. Trying to wrap my brain around Perl to implement
a custom client for my company has been a chore. Add to the fact that
the API is at times inconsistent (domain or reg_domain? just a cookie,
or cookie, reg_username and reg_password?) and it's been quite a
challenge for me. I much prefer, shall we say, a more strict and
structured language like Java or C.
Implementing the client/server API using XML data structures would be a
godsend, as far as I'm concerned. For one thing, there would be a nice
consistent framework to follow when sending commands. Even better, I'd
love to write a client class in Java and be able to do all the same
stuff I have to use Perl for currently. (Sure, I could do the same
thing by "emulating" the Perl data structures, but it's something I'd
rather not have to do...) I like Perl, I use Perl, but for something
the (potential) size of the client I've been asked to build, (lots of
extra functionality other than just the basic OpenSRS client/server API
implementation) I'd rather use something like Java that I can break
apart into a much more modular, and therefore much more managable state.
There are XML parsers/validators for every language I can think of in
popular use (with the possible exception of LISP but if you're writing
an OpenSRS client in LISP, well, you can write your own XML
parser/validator... :) so being able to handle XML structures in your
language-of-choice should not be an issue. The biggest issue, as far as
I can see, is getting the OpenSRS server rewritten to handle XML in/out,
which of course is solely up to the OpenSRS fellows and really out of
our hands. However, if there really is a call for it from the users,
the fact that it has been called _Open_ SRS I hope would have some
influence on the decision makers.
If nothing else, the argument that a proliferation of client code would
probably mean an equal proliferation of affiliates might be
convincing...
My $0.02.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
With Microsoft products, failure is not Derek Glidden
an option - it's a standard component. http://3dlinux.org/
Choose your life. Choose your http://www.tbcpc.org/
future. Choose Linux. http://www.illusionary.com/
