[AOLSERVER] [ aolserver-Bugs-442600 ] ns_info server is broken
Bugs item #442600, was opened at 2001-07-18 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=103152aid=442600group_id=3152 Category: Configuration: Server Group: aolserver3_3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Jerry Asher (jerryasher) Assigned to: Nobody/Anonymous (nobody) Summary: ns_info server is broken Initial Comment: in aolserver 3.3, at the time the config.tcl file is evaluated, the value of [ns_info server] is . It has not been set to the server name yet. -- Comment By: Kris Rehberg (kriston) Date: 2001-07-26 08:58 Message: Logged In: YES user_id=16427 The patch referred to breaks the code that is in 3.x for virtual servers. Since each virtual server has a different response to [ns_info server], and since virtual servers are not initialized until after the configuration file is read, this patch causes undesired behavior. AOLserver 3.x, while not supporting more than one virtual server, still relies on the concept of virtual servers. In fact it has one virtual server, but this doesn't mean we should break the spirit of the concept in making ns_info server work in the configuration. In addition, using ns_info server in configuration files will make them incompatible with the upcoming AOLserver 4 which fully supports multiple virtual servers. Kris -- Comment By: Jerry Asher (jerryasher) Date: 2001-07-25 14:19 Message: Logged In: YES user_id=20647 Sigh, I sure hope we aren't descending into ugliness here. Please let's try not too. I think all of us here want a high quality, stable, useful, fun AOLserver. As I stated earlier (not in my original bug report but in reply to your bug rejection), a patch has already been submitted. In fact, Jamie submitted his patch months before I even realized there was a bug. http://sourceforge.net/tracker/index.php? func=detailaid=421740group_id=3152atid=303152 -- Comment By: Kris Rehberg (kriston) Date: 2001-07-25 14:12 Message: Logged In: YES user_id=16427 The best way to convince anyone that it is a bug is to submit a patch that fixes the bug. Kris -- Comment By: Jerry Asher (jerryasher) Date: 2001-07-19 21:38 Message: Logged In: YES user_id=20647 Hi Pete, I would be very happy with your suggestion, that is an ns_info command that lets me know which server has been requested. But I'm not sure I understand your comment, from 3.0 to 3.2, I have had lots of code within the config.tcl that has definitely required [ns_info server] to be accurate, and it has been. If guess what you are suggesting is that when AOLserver 4 is released, [ns_info server] would not be accurate within the config.tcl since AOLserver 4 will support multiple servers all within the same process. Is that it? Anyway, I would very much like to see either [ns_info server], or [ns_info requested_server] get implemented for AOLserver 4. For AOLserver 3, which doesn't do in process multiple virtual hosts, I'd say it's still broken. It still appears to be a fix that didn't fix all that much, the old behavior was reliable, accurate, and consistent, and users have code that rely on it. -- Comment By: Peter M. Jansson (petej) Date: 2001-07-19 21:14 Message: Logged In: YES user_id=20577 Count me among those who do not believe this is broken. In versions of AOLserver which support virtual hosting, you can't determine the server at config.tcl time, so the parameter is meaningless. I think it might be more productive to have a separate ns_info command to get the server specified on the command line (ns_info requested_server, perhaps?), and leave ns_info server alone. For AOLserver 2.3.3, I had a lot of code that depends on ns_info server being unreliable until virtual servers are started up. I suspect there are others like me. -- Comment By: Jerry Asher (jerryasher) Date: 2001-07-19 11:20 Message: Logged In: YES user_id=20647 Kriston, Is there anyway we can convince you that it is a bug? Or that even if it was a bug, it was a very useful bug? If the user has specified the -s server flag, why not make it available to the config.tcl environment? I believe it to be an unfortunate side effect of the changes in revision 1.22 http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/aolserver/aolserver/nsd/nsmain.c.diff? r1=1.21r2=1.22, when the initialization of the global nsServer was moved lower in the process. This change breaks the existing behavior from the other 3.x releases and will cause many users to have to change and create new config.tcl files. Many of us have config.tcl files that contain the
Re: [AOLSERVER] Easy way to get raw POST data into a tcl variable?
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
Re: [AOLSERVER] Easy way to get raw POST data into a tcl variable?
Just curious, is there a *rough* estimate on when AOLserver 4 will be out? I am not trying to push, just want a ball park figure (days, weeks, months, etc). thanks, --brett 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
+-- 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
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
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 161Tel: (510) 549-2980 Berkeley, CA 94709
[AOLSERVER] Reminder: AOLserver weekly chat today
The AOLserver weekly chat takes place today and every Thursday. Common topics include AOLserver, Tcl, SQL, ACS, and general web-related questions. The place: AIM chatroom AOLserver on exchange 4 The time: 20:00 UTC During the summer, that time is 4 PM US/Eastern 3 PM US/Central 2 PM US/Mountain 1 PM US/Pacific During the winter, that time is 3 PM US/Eastern 2 PM US/Central 1 PM US/Mountain Noon US/Pacific The URL for the chat room: http://www.aol.com/community/aimcheck.adp/url=AOLserverExchange=4 Note: you do NOT need to be an AOL subscriber to access the chat room. If you need more help getting on AIM or getting into the chat room, please see http://dqd.com/~mayoff/aolserver/weekly-chat.html. -- end of message
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
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 Tcl, and it requires no changes to the AOLserver core. Persistent namespaces would rule. Namespaces that can be shared across threads would rule. The combination of both would be amazing. 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. If it's only for the life of the connection, just create a global variable and it'll stay in the interpreter for the life of the connection. If you're talking about data persisting across connections, then use ns_share or nsv. I'm not understanding why you need to extend the core AOLserver functionality to implement something like this. 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? In the global namespace? Then, have ns_log read it from there, calling back into the Tcl API? I could put it into the connections tcl interpreter, but that may risk collision with other applications I load up. That risk is entirely developer error, and is a bug that must be fixed. Isn't there exactly the same amount of risk of another application colliding with your data structure stored in [ns_info meta]? (Does AOLserver 4 supports tcl namespaces? If so that may be the best place to put this kind of information.) 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. 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. Really? Do you have an example of such out-of-band communication? I don't think I've ever come across it, or realized that that was what it was. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
+-- 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 does for global variables. 2. AOLserver does not reset an interpreter's namespace import list at the end of each request. This means that if a request handler calls namespace import foo::x at global scope, then ::x remains mapped to foo::x in subsequent requests. If a subsequent request calls namespace import foo::x at global scope again, it will get an error.
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
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 determined that Ns_DbHandle comes with a spare field, context, that no one uses and was presumably meant for db driver writers to use, if needed, to keep information regarding their driver. I am proposing that a similar field (meta) to placed in the ns_conn structure (and actually filled with an ns_set) in much the same way that the ns_conn carries headers and outputheaders around. I don't want to put it into the tcl namespaces as I don't see other modules communicating with each other that way when it comes to **connection specific** attributes. All connection specific flagging is done with mechanisms built into [ns_conn]. ns_set set [ns_conn outputheaders] contentlength 20 But clearly no one else is enamored with this idea, but maybe if I ask a few questions, maybe I can clarify my points, or I hope, I can learn a bit more about software engineering and making patches to useful, and stable software Question/Example One: Assume for the moment that DCI determines that XML and DOM are just the TLAs they've been looking for to go with AOL, DCI, AIM, etc. So in AOLserver 4, DCI wants to include with every connection the parsed XML of the content of the connection. Where would DCI store that parsed XML? In a global variable in the tcl namespace? Question/Example Two: Setup. nslog isn't reliable implementor of access logging. It doesn't log everything that comes your way. It works as a registered trace, which looking at nsd/serv.c seems to imply that it runs at the end of a connection, after all the other filters run, and ONLY if the connection has a status of of the request was NS_OK or NS_FILTER_RETURN AND if all of the ns_register_filter TRACE filters have returned NS_OK (and not NS_FILTER_BREAK). That said, that can explain why sometimes hits don't show up in your .access log. So assume I want to make nslog even less reliable as I suggested before. I want ANY of my filters or procs or pages to be able to set a flag so that nslog will NOT log that hit. (I don't want to log my site indexer or keepalives.) Assume even further that folks on this list think that in general, that would be a pretty neat extension to have, to enable nslog to have a flag that turns off logging for a page. If DCI made the patch, would they make the flag be a global variable in the tcl namespace? If I submitted a patch to nslog.c that uses a tcl global variable, what would you guys think of that patch, even assuming that you liked the overall functionality it offered? Are there any examples of a (core) AOLserver module obtaining the value of a global variable out of the tcl interpreter and modifying its behavior accordingly? I can't think of any. Am I overlooking something? Thanks, With respect to your question, regarding risks I could put it into the connections tcl interpreter, but that may risk collision with other applications I load up. That risk is entirely developer error, and is a bug that must be fixed. Isn't there exactly the same amount of risk of another application colliding with your data structure stored in [ns_info meta]? I think the risk is greater by placing this information in the global tcl namespace. I believe (mistaken?) that folks have had problems using external libraries and packages within AOLserver due to namespace problems. Even if those namespace problems were resolved, I would like to envision a world where I can use third party packages in my pages without having to worry about naming collisions. I think one requirement then, is to keep AOLserver modules themselves from taking out reserved variables names in the global tcl namespace. Thanks again, Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
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 (or have it pointed out!), not so precise. This is a pretty good reason. But your solution, an Ns_Set in the Ns_Conn (accessible in Tcl using [ns_conn meta]) only allows storing string data. You example of storing parsed XML doesn't fit this model, because you'd want to store a pointer to a data structure representing the DOM tree. Good point. 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 object couldn't be placed in the set, a tcl handle (ala ns_db, ns_xml, ns_set, nsv_set) to that binary object could be placed in there. It would mean that C based modules have another level of indirection to crawl through, those handles are presumably keys into yet another hash table. But is there anything that can be done to generalize further? Jerry = Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161Tel: (510) 549-2980 Berkeley, CA 94709Fax: (877) 311-8688
Re: [AOLSERVER] Proposal: conn specific, spare persistent storage
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 object
couldn't be placed in the set, a tcl handle (ala ns_db, ns_xml, ns_set,
nsv_set) to that binary object could be placed in there.
Then C modules have to go to the Tcl interpreter. In which case why not
just use a Tcl variable?
I'm probably being imprecise again. Well see, here's where it just outside
my domain... (And it's why I open endedly asked what better could be done...)
Is it true that C modules have to go to the Tcl interpreter or is it the
case they just have to create and manipulate Tcl objects? I believe it's
just the latter.
When ns_xml creates various ns_xml objects to represent an ns_xml doc, what
it does is to:
a) construct the name of a handle
b) stick that name into a hash table (getting a hash entry)
c) create an internal doc_info structure
d) fill in that doc_info structure with a pointer to the xml
e) setting the value of that hash entry to the internal doc_info structure
do {
Ns_DStringTrunc(result, 0);
Ns_DStringPrintf(result, %c%u, prefix, info-next_doc_id);
info-next_doc_id += 1;
entry = Tcl_CreateHashEntry(info-doc_hash_byid,
Ns_DStringValue(result), new);
} while (!new);
d_info = doc_info_create(xmlDoc);
Tcl_SetHashValue(entry, d_info);
A connection's tcl interpreter doesn't know anything about this. If
anything, it just passes the handle around as a string. Users do have to
know that this is an xml handle and not a db handle and use nsxml methods
to manipulate it, but there are no variables within the connection's tcl
interpreter necessarily associated with it.
For another c based module to use it, they would a) find it by key name in
the meta set, b) know that that value was an xml handle, and c)
manipulate it using ns_xml methods
Does that clarify my suggestion?
Jerry
=
Jerry Asher [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161Tel: (510) 549-2980
Berkeley, CA 94709Fax: (877) 311-8688
