Exactly... If I load a module, I intend for that module to work... if it doesn't work there is a problem that needs to be eliminated...
----- Original Message ----- From: "Scott S. Goodwin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 18, 2002 11:12 AM Subject: Re: [AOLSERVER] Module arrogance > I agree with Jim's position. If the module isn't working or can't get > what it needs to run, a hard failure will force you to work out the > problem instead of assuming that all the parts were working fine. If the > server continued to roll, you'd really have to test all your modules (by > connecting to the SSL port, for example) every time you started your > server after any change to ensure things really were still working. > > /s. > > > > > -----Original Message----- > > From: AOLserver Discussion > > [mailto:AOLSERVER@;LISTSERV.AOL.COM] On Behalf Of Jim Wilcoxson > > Sent: Friday, October 18, 2002 11:30 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [AOLSERVER] Module arrogance > > > > > > Personally, I like hard failures. > > > > If I configure a database in my nsd.tcl, it seems obvious > > that I want a database. If the server starts anyway without > > one, then instead of having an immediate, obvious error to > > handle, I have a subtle one. I go to my home page, and the > > page comes back, so I assume the server is working. But 3 > > hours later, someone goes to a page that needs to use the > > database, and it dies. > > > > It'd be fine to have a config setting that says "keep going > > if you can", maybe even with multiple values to say how > > severe an error can be before causing a shutdown. In fact, I > > think there already is something like that, or used to be. I > > wouldn't turn it on for critical errors like not being able > > to contact a database. Just my personal preference in > > handling important errors. > > > > An important distinction to me is whether a module decides "I > > can never work", or "I can't do what someone wants for this > > request or at this time". If a module is loaded and knows > > that it can never work right because of circumstances that > > aren't going to change, then I think it's appropriate for it > > to bomb hard. > > > > Jim > > www.rubylane.com > > > > > > > > I think that modules should not issue fatal errors and > > terminate the > > > server unless the module determines that the error it has > > encountered > > > will absolutely prevent correct operation of any part of > > the server. > > > For example, the current nscp module will terminate the > > server with a > > > fatal error if it cannot listen to the specified control > > port, but the > > > server would be perfectly capable of processing HTTP requests > > > (assuming nothing else went wrong), so I'd like to suggest that > > > modules be more conservative in deciding when the server can't > > > continue without them. Database drivers are another > > example -- if the > > > driver can't connect to the DB, there's an API to return > > the failure, > > > and with good engineering, you should be able to construct a server > > > that does something reasonable even in the absence of a db > > connection > > > failure, so a fatal isn't a good idea. > > > > > > Anybody have any feelings one way or the other? > > > > > > >
