At 12/20/03 6:38 AM, John Keegan wrote: >We run 4 perl scripts nightly against the batch RWI. They perform the >following functions: > >1) Get a list of all active domains >2) Get a list of all completed orders >3) Get a list of all deleted domains. >4) Get current admin contact info for each active domain > >These scripts are all based on the "sslbot" code that you can find by >searching the archives. The business reason for running these scripts is to >run our own renewal notification system for the benefit of our non-English >speaking customers. By matching the list of active domains in script #1 with >the current Admin contact info (email address and expiry date) from script >#4, we can send out our own non-English renewal notices and disable the >OpenSRS renewal messages. Scripts #2 and #3 are for database housekeeping, >#2 allows us to verify our order database and #3 is how we know if someone >transfers away. > >I have noted the necessity of running scripts against the RWI as certain >information is unattainable via the API. See some of these posts below for >background: > > http://www.opensrs.org/archives/discuss-list/0303/0269.html > http://www.opensrs.org/archives/dev-list/0207/0046.html > http://www.opensrs.org/archives/dev-list/0207/0045.html > http://www.opensrs.org/archives/dev-list/0207/0041.html > http://www.opensrs.org/archives/dev-list/0207/0039.html > >(Please note that I am specifically speaking to the issue of retrieving >information programmatically so that processes can be automated.) > >I would like to ask the other resellers if I am missing something.
No, you're not, and this is a severe weakness of OpenSRS. (And there are a number of other things that aren't in your list; one that comes to mind because I just needed to use it is forcing a check on the registry transfer status of a domain.) I had a set of extremely long opinions to post about the whole RWI integration thing, but I'm short on time and I'm told nowadays that OpenSRS doesn't have the resources to monitor the list for feedback and do anything about it, so I can't be bothered, to be honest; it's not as if OpenSRS doesn't know it's a problem. In short, though, making things available in the RWI and not the API makes things much more difficult for higher volume resellers. I will make one detailed observation about a slightly related thing that happened to me recently. While scripting the RWI is a "solution", you'll find that when OpenSRS says they don't support something, they really mean it. I found this out when I inquired about the fact that a certain domain name changing to deleted status didn't appear in the RSP renewal e-mail messaging. I was quite literally told that although this omission resulted from an OpenSRS systems problem, OpenSRS didn't consider it important. I pointed out that some resellers rely on this notification to update local database information, and that since OpenSRS sends no other notification of this state change and provides no API function to determine it, it IS important and needs to be reliable. The response was that OpenSRS does not expect resellers to use the data from RSP messaging in that manner (it's intended to be informational, not used as a reference for domain state changes), and that therefore such uses are "unsupported", and that therefore OpenSRS explicitly does not intend to make an effort to guarantee that all deleted domains will appear in the RSP message in the future. Uhhhh... no. If information is going to be provided (especially if it's only being provided one way), I don't think it's acceptable to say "that's only informational, you shouldn't actually have been RELYING on that" when I point out it's wrong. Especially since I didn't find out that OpenSRS considered it unimportant until I noticed it was wrong -- perhaps OpenSRS could place the words "We don't think the info below is very important, and it might be wrong, so you shouldn't rely on it" above all such data so I won't make the same mistake in the future. Seriously, though, we're all running businesses that do rely on this kind of thing, and I think we have a right to expect that when OpenSRS provides data, it's reliable enough to use for whatever purpose we need. This is related to the RWI discussion because I suspect the same thing would happen if your RWI script stopped working. If you're relying on getting a critical piece of info by scripting the RWI, and something changes so that you can't get it any longer, you're going to be told "well, you shouldn't have been using it that way in the first place". I mean, I complained about bad data that was actually being SENT to me and was told that it wasn't supported to use it in the way I was using it, so OpenSRS wouldn't fix the problem -- just imagine if my method of accessing that data had also been unsupported. For that reason, scripting the RWI is not an acceptable solution as far as I'm concerned. I don't think it's a good idea to set up business practices that rely on something that OpenSRS has explicitly said they don't support; I need a supported API method to do everything. >For >example, is there a way to retrieve the current Admin contact info (email >address, owner's name) via the API (without the username/password of the >domain owner of course)? I don't think so, unless this has been added recently. >How about retrieving the current expiry date of a >particular domain? You can now do that with the "belongs_to_rsp" function (until recently, you needed the password). >How about getting a list of your active domains? Nope, and this is my big one. I also do my own renewal messaging and need 100% reliable expiration date information for all domains, and there's no way to get the expiration date unless you query each one -- but that doesn't solve the problem, because you have no way of knowing if you missed one that isn't in your local database somehow. "Trust, but verify." If I could get what amounts to a database dump of all the info related to all domain names in my account, all of these problems would go away; I could use that to do just about anything I needed. After whining about this a great deal privately to OpenSRS people, I've been told that OpenSRS is considering adding a list-all-domains function to the API for the spring. >Is the script "friendly" to the batch RWI? How do you ensure >that your script is playing nice and not "affecting system performance >adversely"? I think by definition RWI scripts are always going to be less friendly than an API version of the same thing directed to the batch servers. However, I figure this is OpenSRS's problem, not mine; if an API were available I'd use it on the batch server. <shrug> -- Robert L Mathews, Tiger Technologies It's just like the story of the grasshopper and the octopus. All year the grasshopper kept burying acorns for winter while the octopus mooched off his girlfriend and watched TV but then the winter came, the grasshopper died and the octopus ate all his acorns... and also he got a racecar. Is any of this getting through to you? -- Futurama
