Andy, While I don't have any experience with this personally (since I'm on the OpenSRS side of things), I do know that several resellers have employed this model.
The one piece of advice I can offer is ensuring that your customers username/password (to access their domain profiles) is DIFFERENT from the OpenSRS username/password - this ensures they are forced to use your systems, so data does not get out of sync (say if they go to manage.opensrs.net or some other reseller's manage). Just be sure to provide a fully featured management component ;) Also note that if you force your customers to use your systems, you must provide a decent level of support. Complaints to us about non-responsiveness of a reseller results in our compliance department sending notices of naughtiness (and you don't want a notice) If you get some feedback offlist, I'd love to hear about it... to more we know about how others are utilizing our API (to its "fullest", if you will) the better visibility we have on how changes may impact our clients (and what components we're more inclined to add). If you find you get less of a response on dev-list (from a technical point of view), you may wish to try a posting to discuss-list and get a different perspective (policies on keeping your clients happy, and using your interface, etc) Charles Daminato TUCOWS Product Manager [EMAIL PROTECTED] On Tue, 23 Jul 2002, Andy Coates wrote: > 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. > >
