i have an idea one should have a seperate hard length and soft length the hard length would be the maximum length a server could handle
the soft length would be the maximum length a client directly connected to a server would be allowed to use so you could increase the hard length slowly first and when it was increaed accross the entire net you would increase the soft lengths >From: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [Coder-Com] New Feature lines purpose >Date: Fri, 2 Aug 2002 17:23:21 +0100 >MIME-Version: 1.0 >Received: from [66.134.137.28] by hotmail.com (3.2) with ESMTP id >MHotMailBF1400D300934136E81B4286891C2B430; Fri, 02 Aug 2002 09:39:52 -0700 >Received: (from undernet@localhost)by trek.sbg.org (8.12.1/8.12.1) id >g72GNUQY004351for coder-com-outgoing; Fri, 2 Aug 2002 09:23:30 -0700 >Received: from mercury.stbarnab.as ([212.115.48.196])by trek.sbg.org >(8.12.1/8.12.1) with ESMTP id g72GNQV2004348for <[EMAIL PROTECTED]>; >Fri, 2 Aug 2002 09:23:28 -0700 >Received: from ground.stbarnab.as ([212.115.48.200] ident=mail)by >mercury.stbarnab.as with esmtp (Exim 3.36 #2)id 17afD1-0002sa-00for >[EMAIL PROTECTED]; Fri, 02 Aug 2002 16:23:23 +0000 >Received: from davidm by ground.stbarnab.as with local (Exim 3.35 #1 >(Debian))id 17afCz-0000wN-00for <[EMAIL PROTECTED]>; Fri, 02 Aug 2002 >17:23:21 +0100 >From [EMAIL PROTECTED] Fri, 02 Aug 2002 09:39:54 -0700 >Message-ID: <[EMAIL PROTECTED]> >References: <000501c23a11$d1c467c0$9b450b0a@netguy> ><[EMAIL PROTECTED]> >In-Reply-To: <[EMAIL PROTECTED]> >User-Agent: Mutt/1.4i >Sender: [EMAIL PROTECTED] >Precedence: bulk > >On Fri, Aug 02, 2002 at 11:35:30AM -0400, Kev wrote: > > > I'am thinking moving NICKLEN, USERLEN, HOSTLEN, ACCOUNTLEN, REALLEN, > > > PASSWDLEN, AWAYLEN, TOPICLEN, NETWORK, URL_CLIENTS to ircu feature >lines. > > > > the *LEN #define's are very particular--they must be exactly the same > > across the entire network and must not be changed during the server's > > operation. Further, they are used to specify lengths of character > > arrays in most cases--that specification must be computable at compile > > time, in order to comply with ANSI C. Making them features is...contra- > > indicated. > >But the sheer fun[1] of implementing these features makes them attractive >to >contemplate, let alone the fun of actually trying to make any meaningful >use >of them.. > >"OK guys, we're changing NICKLEN! Everyone rehash your servers.... >NOW!"[2] > >You should consider putting BUFSIZE on an F: as well :). > >splidge > >[1] for strange values of "fun" maybe.. reallocating all your structures >and >changing all your pointers at runtime without dropping anything is probably >quite a challenge. > >[2] this assumes that you have solved the trivial problem of getting all >your serveradmins awake and on IRC at the same time. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
