There were some good propositions thrown in durring this discussion. I'm really not sure we can provide end-to-end solution, without participation of registries, as I'd like. However, we can make your life a bit easier. I have forwarded one of the proposals to Product Managers for consideration.
Be aware that we will usually not implement anything that may turn out to be maintainance nightmare, and even when/if feature is selected for release, it may be 2-4 months until it's released. Regards, Zeljko Dimic OpenSRS Developer On Thu, 20 Mar 2003, Tim Woodcock wrote: > > > > I don't think replacing transfer call with our own emulation would be > > > step in the right direction. By using emulation, we could be masking > > > bugs in our code that communicates to the registry, as well as possibly > > > registry problems. Our emulation may not be perfect, and we may mislead > > > you to write the code that would work within Horizon, but not in the > > > Live environment. For these reasons, I'd rather keep horizon as similiar > > > to operations of the Live system as possible. > > Much as I would like to test transfers properly and automatically, he is > right. The most important argument against this goes like this: > > If OpenSRS set up the test domains perfectly, it would work nicely, for a > while. HOWEVER should something change, they would have to maintain it. > Chances are high that something would go wrong, be forgotten, changed too > late, etc. That is not a risk I would take if I was in their position > either. It is a maintenance nitghtmare waiting to happen. > > They are not just dealing with a single tld. Their job is quite a lot > more difficult than yours is. If it was easy to set up a direct > registration link to every one of the tlds opensrs provides for you, you > would do it yourself. > > I still like the idea of a special account available only in the horizon > environment that allows us to register say 5 domains in a 24 hour period. > Domains we register to this account COULD be transfered to our own. > > Unfortunatly, while I know our test suite could be set up to do this for > us, I am not sure that other people would be able to use this solution as > easily. > > I'm rambling, and I am really supposed to be somewhere else right now. > > > Providing certain domains which consistantly exhibit a given behaviour > > wouldn't prevent the rest of the domain space from functioning normally. > > So, the communications piece of things would be exactly the same with only > > a few defined exceptions. By making those exceptions function in > > predictable ways you significantly increase the ability of people to > > automatically test client code and the rest of horizon up to the point > > where the shortcut is implemented. So, bugs in communication to the > > registry would not be masked. > > > > It's quite difficult for me to conceive of how any of this would lead to > > code which works on horizon, but fails on live. If there is some > > circituitous set of circumstances that anyone could imagine allowing that > > to happen, shouldn't verifying that you've successfully avoided such an > > error be straight forward? > > > > If this is something that Tucows remains immovably opposed to there still > > seems to be a persuasive enough case to push for the various test > > registries (or at least one) to implement this. The example of having > > certain credit card numbers available which have predictable behaviours > > shows that it's not only a desirable feature, but implementable without > > adversely affecting the ability to test end-to-end operation. Tucows is > > obviously in a much better position to persuade some registry to implement > > this than we mere resellers. > > > > -- > > </chris> > > > > The death of democracy is not likely to be an assassination from ambush. It > > will be a slow extinction from apathy, indifference, and undernourishment. > > -Robert Maynard Hutchins, educator (1899-1977) > > > >
