> 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 It doesn't appear to be too modular to me.. It's scattered through the entire code. Basically because the users input could be in any of five languages, as well as the return. I think that may be the logic behind it. > the functions could be placed in a different file and imported on condition > of race=true or something. the basic idea I applied I guess, but just switching the code in place, rather than importing it. That's a good idea worth looking at. > 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. That's an excellent idea actually. Even though I said I wasn't going to do much with the ideas I may still have a play with that idea and see just how difficult it is to implement. I'd certainly like to see the whole deal modularised a bit. Especially when it comes to adding inhouse stuff like cc processing. Modules make it soooo easy. bob > > -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 > > > > > > >
