+-- On Jul 26, Jerry Asher said:
What do you folks think?
I think you should just use a global variable. Pick a name. Let's say
ns_meta. Use it as an array.
set ::ns_meta(no_log) 1
I vote with Rob to use a global variable for data storage, not a function.
Accessing variables with functions ala [nsv_set/get/whatever is problematic
because they are not general. You can't pass them to functions. They
aren't first-class variables, so any time you use them, you have to be
On 2001.07.26, Jerry Asher [EMAIL PROTECTED] wrote:
My desire is to create a clean, standard, understandable mechanism that
allows one module to communicate with other modules (regarding processing
of a specific connection).
What's wrong with using Tcl8 namespaces? They're a working part
of
+-- On Jul 26, Dossy said:
AOLserver 3 supports Tcl namespaces, at least nsd8x does. I
do recall hearing that there were some problems but I'm not sure
what those problems are.
Two problems:
1. AOLserver does not clear namespace-scoped variables at the end of
each request, as it
I would like to see an [ns_conn meta] of some sort, to make it possible for
existing modules, new modules, registered filters, registered procs,
registered traces, and even pages to annotate a connection with various
connection specific flags, attributes, or data.
Dossy, I think we once
At 01:20 PM 7/26/01, Rob Mayoff wrote:
C modules that wish to communicate connection-specific data
shouldn't be required to use the Tcl interpreter to do so. You sort of
talked about this reason but didn't state it precisely.
Yes. I often believe I am being very precise, only later to realize
At 02:32 PM 7/26/01, Rob Mayoff wrote:
+-- On Jul 26, Jerry Asher said:
But at first glance, what I would probably want to store would be Tcl
objects, so that we could write functions to make this meta data available
to Tcl procedures. So while a pointer to raw binary parsed xml
