I am not using it so i have nothing to add to existing API. As for the name, maybe ns_process or ns_exec ?
Zoran Vasiljevic wrote:
On 04.10.2006, at 10:03, Zoran Vasiljevic wrote:To summarize. What you object is: a. handle management (should work without handles) b. name of the module (should not be proxy) c. invent default pool d. ? For a: I understand the syntactical need, but this is how I see that from the practical side. By having a handle, I can run "things" in the proxy (lets call it slave process from now on) one after another with a possible "state" between the runs. This might sometimes be needed. If I hide the handle, how could I force my two or three consecutive operations to be executed in the same slave? For b. I do not care how we call it. We can call it ns_cocacola if you like. The name contest is open... For c. I'd rather stick to explicit pool naming. I'd leave this "default" to the programmer. The programmer might do something like (not 100% right but serves the illustration purpose): ns_proxy config default rename ::exec tcl::exec proc ::exec args { ns_proxy eval default $args } This covers overloading of Tcl exec command. If you can convince me that there are other benefits of having the default pool I can think about them. I just do not see any at this point.So, how we are about to proceed on this matter? Are there any comments/ideas about naming? Handle managment? What I'd say is (in a nutshell): a. I think handles should be left as is (after all you also open a file, get the handle and then use it to write/read, or?) b. I do not like the name very much but I can't think of better. c. I would not "invent" a default pool. I would leave this to the programmer. The default pool just does not fit in and it would make the API more (instead of less) complicated. Overall, I'm more/less happy with what we have now. I could imagine adding some more config options to limit the resources in the slave (memory, number of open files, absolute execution time etc) but this can be added during regular maintenance. The most important thing now is to freeze the API. The API is now well-documented and I invite everybody to read it and suggest better one so we can vote. I have no vested interest. I will bow to the will of the majority. Cheers, Zoran ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ naviserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/naviserver-devel
-- Vlad Seryakov 571 262-8608 office [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/
