Hi Andy, Our client was designed to help automate domain management and support tasks as well as to integrate with hosting, DNS, and email services. Mirroring the username & passwords were necessary to accomplish this, but once you've done that, then fetching contact information & other domain attributes via the API can be done pretty easily. We elected to keep everything that we could external to minimize the problem of data becoming out of sync with the OpenSRS tables.
That said though, our next client will likely use a version of handles for contact information to be kept locally. Doug. Quoting Andy Coates <[EMAIL PROTECTED]>: > > Hi Andy, > > Hey Doug, > > > 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. > > I'm curious as to why you didn't elect to store contact information, can > you expand on that? This initially was an area I wasn't too sure about, > mainly due to amount of desync that would occur if contact information > was stored too (as opposed to just the dataset you listed). > > Thanks, > Andy. > > > Thanks, Doug. -- Doug Friend http://register4less.com
