Hi Andy, The client we've written does store some of the same info that are a part of the OpenSRS data set. We elected not to store contact information, but do store user/pass combinations, expiry dates, and the information that is provided with the initial order. We're also working on adding a whois capability to better deal with transfers and their problems.
The biggest problem with this as you've pointed out is keeping our dataset in sync with OpenSRS. Many if not most hosting companies will direct registrants to make changes in their domains directly from manage.opensrs.net, and if a password gets changed their, this causes a problem. When this happens, we send the registrant their username & password from via the RWI, and ask that they echo this back to us so we can resync the account. Keeping things in sync however is manageable. We have been asking OpenSRS to add a pointer to the login page on manage.opensrs.net to direct registrants to login directly from their resellers page when available. Our thinking was that this could be configurable in the same manner as the transfer confirmation page. Hopefully soon:) Cheers, Doug. Quoting Andy Coates <[EMAIL PROTECTED]>: > Hey folks, > > I was looking over the mailing list archives and noticed a few people > using local DB's to store data for quicker access. > > What is the current feeling about which data is most effective being > stored locally? Obviously if access is given to an external management > interface there will be desync problems - but apart from that it seems a > lot nicer (and less burden to the OpenSRS server) to perform all > "reading" functions locally and then "writing" the updates to OpenSRS. > > So before I go ahead and write tons of code using the API, has anyone > come across any problems with such a setup? > > TIA, > Andy. > > > Thanks, Doug. -- Doug Friend http://register4less.com
