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
