> > 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) >
