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
aware of the context and/or pass other flags around to say "this isn't
a variable, it's an [nsv thingy". Then your code has to test this flag
and basically duplicate itself using the [nsv routines, or you have to
copy data from [nsv into a real variable, pass it around, then make
sure you copy it back when you're finished operating on it.
Just another opinion to throw into the mix.
Jim
>
> At 09:49 AM 7/26/01, Kriston Rehberg wrote:
> >I've been given to understand that it's because the functions that handle
> >data coming in from the client gobble up the data and don't leave it behind
> >in an intact form. AOLserver 4 is going to allow seeking around the
> >incoming data, headers and all.
> >
> >Kris
>
> This will be nice.
>
> I've been thinking that it would be very nice to have a place (ns_set
> really) in the connection structure that filters, procs, pages, etc. could
> store data into that would be automatically cleaned up when the connection
> is closed.
>
> [ns_conn meta]
>
> => a connection specific ns_set to be used for application layer, conn
> specific information.
>
> The kinds of data I would like to store would be meta-data about the
> connection that one module or filter might use to communicate with another
> filter or module.
>
> 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). Importantly, it would make it easier to develop
> clean and robust extensions to "classic" core AOLserver modules. So if one
> developer made a patch to ns_log or ns_xml or ... that looked for or set
> flags, etc. in this meta set, other developers would not instantly reach
> for their barf bags.
>
> For instance, it might make XML processing more efficient (or easier to
> develop), if a DOM parse could be built/stored/retrieved in this meta space
> during the life of the connection. My understanding of nsxml is that it
> returns a handle to the parse tree that everyone needs to carry around. It
> might be nice to be able to store that handle in the meta set of the
> connection.
>
> ns_set put [ns_conn meta] xmlhandle [ns_xml ...]
>
> As another example, I've been playing with various site indexing engines
> (htDig and SWISH). They do a great job, but their crawling wreaks havoc on
> log files. I want to log how others access my sites, not how my sites
> access themselves. Similarly, I have been playing with a simple keepalive
> function and that too does a number of log statistics (one of the most
> popular pages on my sites is NOT /SYSTEM/dbtest.tcl). In response I
> created a small filter that detects certain aspects of a connection and
> creates a piece of information that tells ns_log NOT to log that connection.
>
> But where can I store that piece of information?
>
> I could put it into the connections tcl interpreter, but that may risk
> collision with other applications I load up.
>
> Eventually, I took the horribly tacky approach of putting it into the set
> of input headers. Bleh. Embarrassing. (And it creates a bit of a
> security hole.)
>
> ns_set put [ns_conn headers] no_log true
>
> But it did what I wanted: persistent meta data about a connection stored
> away from typical user space in a manner that lets robust, coherent,
> understandable extensions get added to other modules. So in this case, I
> made a very simple patch to ns_log that looks for that header, and seeing
> it set, returns without logging the access
>
> I would prefer
>
> ns_set put [ns_conn meta] no_log true
>
> I believe I recall seeing some ArsDigita procs store this sort of
> information using nsv_sets where the conn is the key, and that works, but
> just doesn't feel like the nice clean understandable mechanism that
> [ns_conn ...] is. To use such a mechanism, all the modules have to agree
> on the name of the nsv_set for instance.
>
> And I am also pretty sure this can be done by storing the information into
> a standard variable within the connection's tcl interpreter, but again
> modules have to agree on the variable name, and placing the data in
> variables in one namespace risks collisions with other libraries that we
> may wish to load (Does AOLserver 4 supports tcl namespaces? If so that
> may be the best place to put this kind of information.) But also, drivers
> today don't read/write/store any information (except result and error
> information) in the tcl interpreter. All of their communication is done
> out of band in ns_conn structures.
>
> What do you folks think?
>
> Jerry
>
> =====================================================
> Jerry Asher [EMAIL PROTECTED]
> 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
> Berkeley, CA 94709 Fax: (877) 311-8688
>
