> 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).
Yes I have already developed that part of it, I was basing it on the fact that until they say otherwise they will be using my system to manage their domains - so they never need know the true domain user/pass until they no longer wish to use my system for whatever reason. When that time does come (say I have a huge network failure or some other long-term downtime) they can still control their domains via manage.opensrs.net > 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) Luckily I won't be selling to your average, pardon the expression, "idiot". I'm being very open with my customers about how the system operates, so they will be aware they can use my systems or simply register the domain via me and use an alternate management interface. > 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). Everything I am writing is based on the php library, and so far has been very easy to work with the API - the docs you provide are very well written and easy to understand. Andy. > 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. > > > > > >
