Re: [naviserver-devel] nsproxy API

[Zoran V. <zv...@ar...>]

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