On 10/6/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 06.10.2006, at 22:21, Vlad Seryakov wrote: > I vote for ns_exec and putting it into the core OK. Couple of simple thoughts agout that: ns_exec ?-pool poolname? script ?arg ...? is nice and short. It uses the default pool (as Stephen is advocating). But... how would we create pools, configure pool-wide options etc pp? As I could not figure that out, I thought it would be better NOT to specify the action (i.e. exec) but the vehicle (the slave process) hence ns_slave. Now you can easly replace ns_proxy with ns_slave and all (most) subcommands read nice... So we have now: ns_process ns_exec ns_slave ns_slave and ns_process specify the thing and subcommands the action. it is trivial to expand to include pool management commands but api is rather "large" or "clumsy". ns_exec specifies an action only. it is difficult to fit in any other "action" for pool management for example but is small and compact. Any other idea? (Sometimes it can ve REALLY difficult to give baby a name...)
ns_exec works for me as well. I guess the wording doesn't work so well for the sub-commands, but it does explicitly say what's special about this command, whereas you'd have to read the docs for ns_salve. ns_process is a good idea, but it feels like a very generic word to me. It could imply an individual OS process, but I also think of it more as an action: to process: 'do stuff' to this thing: 'process the loan application, Miss Higgins...!'
