I took at a look at the code in the client. Here's the snippet of code
from manage.cgi 2.49 (around line 752):
if (not $rsp_forwarding_email->{is_success}) {
$error .= "Failed to modify forwarding email for
$reg_domain : $rsp_forwarding_email->{response_text}<br>";
$resultString .= "Failed to modify forwarding email for
$reg_domain : $rsp_forwarding_email->{response_text}<br>";
} elsif ($rsp_forwarding_email->{response_code} = 300) {
$error .= "Forwarding email modification successfully
submitted, could take up to ".time_to_wait().".<br>";
$resultString .= "Forwarding email modification
successfully submitted, could take up to ".time_to_wait().".<br>";
$ok_flag = 1;
} else {
$error .= "Forwarding email modification successful for
$reg_domain<br>";
$resultString .= "Forwarding email modification
successful for $reg_domain<br>";
$ok_flag = 1;
}
notice the "elsif" that checks for response code 300 for delayed
success. Then the final else for full success. This means no code
changes for when .name go synchronous. Client 2.49 should be usable for
future sync nameserver, forwarding email and (eventual) contact changes.
Dan
Robert L Mathews wrote:
>At 2/6/02 11:09 AM, Rick Baraniuk wrote:
>
>>Only during startup due to the 'asynchronous' nature of submissions.
>>When the registry moves to real-time, so will the ability to make
>>nameserver/other changes.
>>
>
>Ah, okay. That's good.
>
>A minor bug report, then: the code doesn't seem to make that distinction,
>which means that if someone installs 2.49 now, then continues using it
>when .name goes live, it will still display a message to end users that
>their nameserver changes will take up to 21 days.
>
>--
>Robert L Mathews, Tiger Technologies
>
>"The trouble with doing something right the first time is that nobody
>appreciates how difficult it was."
>
