> > 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)
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:39 EDT