page@ulowell.cs.ulowell.edu (Bob Page) (07/06/87)
Kim DeVaughn wrote: >Bob Page makes some very good suggestions for the "daemonization" >of thinks like Facc, popcli, etc. spencer@eris.BERKELEY.EDU (Randy Spencer) replied: >[commodities.library is] exactly for things like those mentioned above. I was talking about two different ideas, and you and Kim apparently latched on to different ones. He was talking about my idea of command line parsing, then starting up the daemon and passing the options to it in a message somehow. commodities exchange is not meant for this. In fact, the program does not have to be daemon-like to get gains from this ... a small program that has a lot of options (like say a cross-referencing program) could do its command gathering/parsing in a front end program, then start up the small back end task and pass it a message that has all the options set. The net effect is that you throw away all the command parsing code after you're done with it, since you only use it once. It is MOSTLY useful for daemon-type programs, since they stay around for a long time, and saving 3-12K (depending on how much parsing and error checking/reporting you'r doing) for the life of EACH program is nothing to sneeze at. However, it can be used to good effect on other non-daemons too. On another note, I thought about a 'proposed standard' for doing this, and decided one wasn't necessary. As Perry pointed out, just using the existing Message struct is enough. You'd have to design your message body in whatever format you need. For example: struct Opts { BOOL foldcase; /* if uc should be folded into lc */ BOOL linenum; /* if line numbers are desired */ USHORT debug_level; /* zero if no debugging required */ LONG heapsize; /* specified heap size */ } opts; you get the idea. Once the front end does its thing and passes the options message, it goes away. From then on the back end only has to say things like: if (opts.foldcase == FALSE) or whatever. So there's my proposed standard. :-) ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}