RE: [NeoStats-Devel] [Commits] r363 - branches/3.0

10 modules performing a strip would be much more of a waste of CPU cycles
than a single one in the core, hence the idea of storing both a real form
and a stripped form. But if we only ever use the stripped form, it is a few
bytes saved to store it once.

As an example, SecureServ and StatServ use version. They both have to call
strip. It would therefore save more cycles stripping once in core than
stripping twice in modules. 

If the is never likely to be a need for the unstripped form, we could store
just the stripped one.

Mark. 

> -----Original Message-----
> From: Justin Hammond [mailto:justin-kLev/[email protected]] 
> Sent: 29 August 2005 16:05
> To: [email protected]
> Subject: RE: [NeoStats-Devel] [Commits] r363 - branches/3.0
> 
> I would actually keep it in original form on the user struct, 
> and let the user decide if they want to strip it. No use 
> stripping the version reply if we don't have SecureServ 
> loaded etc, just a waste of CPU cycles IMHO.
> 
> Thanks
> 
> > -----Original Message-----
> > From: M [mailto:[email protected]]
> > Sent: Saturday, August 13, 2005 6:43 AM
> > To: [email protected]
> > Subject: RE: [NeoStats-Devel] [Commits] r363 - branches/3.0
> > 
> > 
> > > From: [email protected] [mailto:[email protected]]
> > > Author: Fish
> > > Modified: branches/3.0/scan.c
> > >  int ScanCTCPVersion(Client *u, char* buf)  {
> > > +	strip_mirc_codes(buf);
> > >  	return Scan(DET_CTCP, u, buf);
> > >  }
> > 
> > Is there ever likely a need for us to use an original 
> unstripped form? 
> > If not, maybe we should strip core side. I am also 
> considering storing 
> > the CTCP responses such as this in the User struct so we could 
> > potentially store both but I am not sure if there is any 
> worth in the 
> > original form.
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> > For additional commands, e-mail: [email protected]
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> For additional commands, e-mail: [email protected]
> 
>