On 2003.05.31, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > Doable, but messy. IMHO. nsd already takes care about pid-file > logfiles, etc when going to background. This is all nice stuff > and I wouldn't like to reimplement all this in an external shell-script. > Why just not put this logic on the C-level in the nsd? It is already > forking to background. Why not fork one more time and get a nice > controller/worker tandem?
How many lines of code and how many man-hours will it take to implement in C? How long will it take to review all the code to ensure you've neither introduced any new bugs or otherwise broken already existing code? > > As I said, I think implementing this directly in code with a > > user-selectable command line switch might be really convenient. But, > > it's obviously not necessary to achieve the same results ... as you can > > do it simply with a 8 line shell script. > > This is right. It is the convenience of having a well tested, working solution > which you just use w/o shell-script workarounds. Somebody has to write, > update, maintain, etc... this shell-script, right? Um, it's an *8 line* shell script. It took me about 20 minutes to write and thoroughly test the first time I ever wrote it. There's nothing to update or maintain either, really. I'm betting a beer that to do it right in pure C, with all the necessary regression testing of nsd and so on, will take far more than 20 minutes. I'm not one to push cost vs. benefit, but ... what's the benefit of having done the extra work to do it in C when the benefit is EXACTLY the same as doing it via my shell script? > Now, what I did not say (nor done yet, but I'm planning to) is: win32. > You have no shell there. By having all built-in, you have no worry. I'd still rather write a general purpose process monitor and service runner for Win32 so that MANY other folks could use it to run all sorts of different things, nsd being just one of them. Then, it'd also remain decoupled from the nsd code ... Also, as a stand-alone script or program, folks running even older AOLserver 3.3.x could take advantage of it, rather than being forced to upgrade to either 4.x or 3.5.x ... or were you planning to backport this change all the way back? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
