At 9/12/01 3:37 PM, Kai Schaetzl wrote:
>Sure, but the time lag just depends on how fast the mail is getting
>processed and the registration itself is getting processed. F.i. we do
>not use OpenSRS as our primary registrar for new domains because using
>the CGI system simply isn't feasible for us. We take orders from our
>clients fully independently from any registrar or registry, our clients
>do not get in contact with registrars/registries in *any* way. So, we
>just take that order into our database, check it for
>correctness/validity/credibility and then submit it from their via
>email.
Why not just create a little program that converts your e-mail to
something the existing OpenSRS software can use?
When you send e-mail to a certain address, that e-mail delivery could be
piped to a program which parses the message and attempts to register the
domain via OpenSRS's standard code. If it can contact OpenSRS, your
program returns a reply. If it can't, your program rejects the e-mail
with a "temporary failure", and the e-mail program tries delivering it
again (thereby running the program again) a few minutes later.
This could all be hacked up on a Unix box in perl in less than a day. I
recently did something unrelated but similar in concept that takes e-mail
input, parses it, and makes database queries with it: if the database is
down, it returns a temporary failure code to make the e-mail program try
again later. It took me less than an hour to get a basic version working.
Given that such a system would be more flexible for your needs than
anything OpenSRS could come up with, this sounds like a much better
approach than asking OpenSRS to come up with a whole new interface. You
could even use your existing e-mail templates instead of having to create
new ones -- it's less work for you than it would be to switch to a brand
new OpenSRS scheme, and OpenSRS doesn't need to do anything.
--
Robert L Mathews, Tiger Technologies
