I haven't looked much at the race code; I've been trying to avoid it. I
would think, though, that it should all be quite modular. If so, then all
the functions could be placed in a different file and imported on condition
of race=true or something. Then, those of us not wanting it don't get it,
with no additional parse time etc. Similarly, each of the addional TLDs.
There is a ton of code for .ca, which I do use... and .tv on the way, and
many others. Keep each in a separate file to be included only if desired.
That would mean dozens of little library files instead of one big reg_system
and one big manage.

-Eric


-------------------------------------------------------
arctic bears - the internet - your way.
50000 domain names were reserved today. was yours?
domains from US$25/year, name resolution, mail hosting.
http://www.arcticbears.com


----- Original Message -----
From: "Robert" <[EMAIL PROTECTED]>
To: "Opensrs-Dev" <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 5:09 PM
Subject: Looking at options for bypassing RACE. Just some thoughts on the
subject


> I just spent some time playing with bypassing RACE parts in 2.23's
> renew.cgi - using that as the smallest example of code with RACE
components
> in it.
> I put a
>
> %RACE (
>                race_on => 0;
>          );
>
> into OpenSRS.conf first, then in renew.cgi located the RACE and encoded
> bits - mostly held together, and did a pretty basic job of using
>
> if ($RACE{race_on}) {
>    # do the bits race needed,
>   } else {
>   # do the same bits but cleaned of race code
>  }
>
> It basically worked - and would have worked ok if I spent more time on
it...
> I wasn't about to do that though, as it would need doing with every
release.
> It would also mean a few additional templates. Those with RACE code, and
> those without.
> The gains in compile time were not all that significant, although RACE
does
> take a looooong time to load!
>
> The big job of course would be reg_system, and manage.
>
> My conclusion is that it could be done one of two ways:
>
> 1. Lots of embedded {if-else} statements. An onerous task for some poor
> programmer! However, it would mean that those who are fully embracing the
> MLDNs against future implementation still have the fully functional system
> as it is upgraded over time. It's a simple switch in the .conf file then.
> However - the extra code means extra processing, so what is saved by not
> loading RACE is probably lost in the extra if-elsing code. I didn't do a
> debug/profile.
>
> 2. Strip the RACE code out of the releases all together, leaving these
early
> versions as the bedding for the _future_ introduction of fully functional
> MLDS. Which would appear to be some years away yet, and more than likely
not
> even based on current methods.
>
> There is a third option of course. Rework your templates so that there is
no
> sign on the RACE parts, and just ignor it untill it's needed, and put up
> with the load time pressure. Probably the easiest method, and what I
suspect
> most have done.
>
> anyway, just thought I'd let interested parties know it can be done... but
I
> wouldn't expect the OpenSRS team to have it high on the list of
priorities.
>
> What do others think?
>
> Bob
>
>


Reply via email to