Re: [AOLSERVER] Aolserver Progress - Some few examples....
On Aug 4, 2011, at 12:24 AM, Maurizio Martignano wrote: inttrigger[2]; /* Wakeup trigger pipe. */ ß Why is this an int when it was a SOCKET (any justification) A Unix pipe is just a pair of file descriptors, and a file descriptor in Unix is just an integer. Windows pipes are implemented differently, of course, and the semantics aren't exactly the same, either. Can you tell from CVS who put this code in? I'm sure it was done from ignorance of Windows vs. Unix differences regarding pipes, not intentionally. I have the feeling that we are not facing Windows specific stuff, but somehow some general errors, mistakes that happen to manifest themselves only on Windows (64). Not in this case, no, that's perfectly reasonable Unix code. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
On Aug 4, 2011, at 7:20 AM, Maurizio Martignano wrote: 5. I have to disagree with your statement A Unix pipe is just a pair of file descriptors, and a file descriptor in Unix is just an integer. Feel free to disagree with the official Linux documentation then: http://www.kernel.org/doc/man-pages/online/pages/man2/pipe.2.html Note int pipefd[2] file descriptors in Unix are integers. Dossy says this is the same in Windows (I wouldn't know), perhaps the problem lies in the semantics, IIRC windows doesn't support anonymous pipes, for instance. (But I could be wrong about that … but I'm not wrong about Unix fds being ints) Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Aolserver Progress - Some few examples....
On Aug 4, 2011, at 9:55 AM, Maurizio Martignano wrote: All of this depends on the week type system of C, were types with different names, supposed to be used for different needs are considered equivalent is their size is the same. If we had used Ada none of this would have had happened: types with different names are different no matter what their size is. If we were using Ada a file descriptor in Unix would still be described as an integer. I'm not saying that the Unix code you've uncovered is portable between Unix and Windows. I'm just pointing out that pipes are defined as an array of two integers in Unix, so that the code isn't wrong for Unix, as you originally claimed. I did so hoping it would increase your understanding, i.e. your claim that it appears to be a bug even in Unix is incorrect. If you want to make progress here, just accept that the code is perfectly good Unix code and then figure out how to make the code work for both Unix and Windows, instead of trying to argue incorrectly that the code's not correct for Unix. It's not portable, but it's correct for Unix. Thank you. Anyhow in the base code 95% of the times or even more sockets are declared as SOCKET sockets. Here and there they are declared as int. This is an inconsistency and it should be removed. I do beg the community to do this little change because it is in the benefit and interest of everybody. I'm sure that the community will accept a patch that declares the pipe in a way that makes both Unix and Windows happy if you'll provide one. Meanwhile, quit complaining because I pointed out that, in Unix, int pipefd[2] is the correct declaration for a pipe. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 11:31 AM, Jeff Rogers wrote: I get down into these filters trying to figure out why my OpenACS installation returned error pages for bad urls instead of the configured 404 page. What appears to be going on is that a preauth filter rp_filter is set up to do authentication and some other initialization (importantly, populating ad_conn values), while the main request processor is rp_handler which dispatches the request via a number of different mechanisms and if it fails all of those falls through to ns_returnnotfound, which does the internal 404 redirect. However, the 404 page will also get handled by rp_handler, but based on the values in ad_conn (specifically, extra_url) that are only set up in the preauth filter; if the filter is not run again then it tries to handle the internal 404 url based on the original url and fails again, until it hits the recursion limit and just given an error. (BTW, setting up a 500 error page here crashes the server by overflowing the stack.) This also makes it! impossible to use acs-templating on the 404 or 500 error page. Yes, this has been a known problem and known to be due to the fact that filter's not being run. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 2:08 PM, Jeff Rogers wrote: Well my question for now is, if this was fixed/changed in a way like I've suggested, how long would it be before OpenACS could take advantage of the change? Wouldn't it just work automagically if the filter were run and context set up properly by rp_filter? Are there other aolserver bugs/inadequacies that openacs works around that could be improved? Not that I'm aware of at this point, though Gustaf Neuman of U Wien might have something. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 4:49 PM, Jeff Rogers wrote: Of course, this is all theoretical right now. It would be a lot easier to reason about it if there was a real use case. Yes, it is. There's very little development activity around OpenACS these days, and I can't think of anything in AOLserver that's begging for improvement from the point of view of the toolkit (contrary to an opinion stated in a previous post, the request processor implementation is efficient, and isn't an indication that the implementer didn't understand AOLserver, indeed filters are provided exactly so the kind of processing done in the request processor can be done). Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 6:07 PM, Andrew Piskorski wrote: On Mon, Jun 06, 2011 at 05:31:44PM -0700, Don Baccus wrote: (contrary to an opinion stated in a previous post, the request processor implementation is efficient, and isn't an indication that the implementer didn't understand AOLserver, I don't recall the details I don't doubt this in the least ... Clearly OpenACS didn't need any other special AOLserver filters so it was reasonable to do its request processor the way it still works today, rather than something more general which might look better from an AOLserver-centric rather than OpenACS-centric point of view. You know, I'm involved with people doing RAILS work today, and I don't recall anyone making the argument that the platform should be more Apache-oriented rather than RAILS oriented, etc. Same with, say, Django or other web application platforms. My point here was merely that I'm fairly sure that whoever implemented the ACS/OpenACS request processor approached the problem very much from the point of view of, AOLserver is just a tool to implement OpenACS; what's one good way to make it do what I want for OpenACS? Ahh ... your point was that whoever did the work at aD was a good software engineer, an excellent one, a point you didn't make particularly clear in your first post. Well, I agree. Whoever wrote that code did a good job. Nothing wrong with that at all, but it has different implications than, I use this AOLserver tool in a lot of different environments, what seems to be the best way I can have it support what one of those environments, OpenACS, needs? arsDigita (which I was never associated with, and was never paid a dime from, and which pretty much hated me) was right to make this decision the way they did. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] hacking around
On Jun 6, 2011, at 12:25 PM, Andrew Piskorski wrote: In general, I don't think the ACS/OpenACS 4.x request processor design was EVER carefully thought out with respect to all of AOLserver's features and use cases. Or, in this case, didn't understand the bug that the internal redirects on various errors like 404 didn't run the filters. Of course, in AOLserver 3.0 (underwhich the rp was first written) perhaps AOLserver did ... I admit to being somewhat astonished by the lack of orthogonality when I figured this out in the AOLserver code. It wasn't documented, and actually, rather than being an example of the rp's design not being carefully thought out in regard to AOLserver's features, I'd say that the design exposed a bug. The OpenACS rp_* Tcl code just grabs control from the AOLserver mechanisms. And this is just stupid. If the AOLserver paradigm is that people shouldn't write filters, it should not provide the facility to write filters. QED and all that. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 6, 2009, at 1:49 PM, Tom Jackson wrote: The requirement is the ability to handle both the empty string and NULL. Personally I like the Oracle behavior. I mean ... it might help if you actually *knew* the Oracle behavior before posting an opinion, positive or negative, about it. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 6, 2009, at 1:49 PM, Tom Jackson wrote: The requirement is the ability to handle both the empty string and NULL. Personally I like the Oracle behavior. I mean, hell, there's even a daily WTF post about it: http://forums.thedailywtf.com/forums/p/1225/26879.aspx (in which many respondents prove they don't understand the SQL concept of NULL, but that doesn't matter) In SQL the empty string is the empty string. In Oracle, it's equivalent to NULL. Not at all the same in SQL, but the same in Oracle. Just go away until you 1) understand the SQL standard and 2) Oracle. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 6, 2009, at 9:19 PM, Rusty Brooks wrote: And in regards to protecting from sql injections, using ns_dbquote and the binding emulation both seem like they'd do the trick. If a user types in NULL and you call ns_dbquote, you'll get 'NULL'. Just as with the binding emulation. The only way to have the literal NULL act as the SQL NULL is by essentially removing the string 'NULL' from the set of inputs that will result in a string being put into the database. If your bind variable or quoted variable contains something like NULL or a bit of SQL or a special column like the postgres equivalent of sysdate which is slipping my mind at the moment current_timestamp, which is standard SQL. , then you won't get what you expected probably, you'll get the literal value. That's kind of the price you have to pay if you want to put values that come straight from a user into the database safely though. Yes, indeed. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 6, 2009, at 9:16 PM, Rusty Brooks wrote: Why is it that you can't get out what you put in? 'is null' doesn't make a lot of sense to me to begin with (please, just accept test=NULL!) Oh, it makes perfect sense within the formal framework of SQL. no value is not the same as a value which is empty. The difference isn't as obvious with strings, but i = 0 is not the same as I have no value for i. Unknowns are important. In Tcl we do it typically by saying [info exists i] ... that's how you tell if i has a value or not. If it wasn't useful to know if i has a value or not, well, why have info exists? SQL is just a bit more explicit ... i is null is essentially like ! [info exists i] but the fact that oracle turns my '' into a null means that I can't get my results back without turning any queries that have test = '' into test is null Yes, the confusion in Oracle is bad ... Postgres still makes me use is null Better is to say SQL ... not Postgres - Postgres implements the standard. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 4, 2009, at 12:03 PM, Tom Jackson wrote: The problem remains for other databases using the ns_db APIs. The quoting examples are general, but don't always work. The person's using PG so a PG-specific solution solves the problem. No reason to make this more complex when a simple solution suffices. Another problem is working with nulls. You can't quote null and postgresql distinguishes the empty string from null. Tcl doesn't implement the null concept. 'set foo ' sets foo to the empty string, not null. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 5, 2009, at 10:34 AM, Rusty Brooks wrote: I'm not sure what would happen if you had actual binding, like the oracle driver and did this If you want to learn how Oracle bind variables work, the Oracle documentation is online ... set val NULL set sql update mytable set mycolumn=:val You get 'NULL', not NULL, as is true with the bindvar emulation we do in the postgres driver. but I suspect it would work as expected (you'd get NULL in the column). You'd be wrong. The compatibility mode, as it's described (never used it) is very nice but probably doesn't act like actual variable binding in every possible case? Yes, it does, actually, it treats the empty string as NULL, just as happens with Oracle bind variables. That's why we called it bindvar emulation when we did it ... if it didn't properly emulate Oracle it wouldn't be very useful for writing queries that work the same in both RDBMS's, which was the whole point of the exercise in the first place (safety against SQL smuggling is a nice side-effect, but was not the motivation for providing this in the driver). Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 5, 2009, at 5:13 PM, Tom Jackson wrote: Really? The title of the post says AOLserver is vulnerable. No, it says ... [AOLSERVER] Is this vulnerable to sql injection? [AOLSERVER] is the name of this mailing list, not the antecedent of this. this is defined in the body of the message: I've been alerted that a site I maintain, running on AOLserver 4.5.0 using the nspostgres driver, may be vulnerable to sql injection. Hmmm, nspostgres driver, which RDBMS is he using, I wonder ... Tcl can write a query string which uses the keyword NULL. Unfortunately the simple (but very nice and also safe) bind variable concept doesn't handle this common requirement. You've got it backwards, it's the empty string, not NULL, which a bind variable in Oracle (or in our emulation for postgres), doesn't handle - it becomes NULL (this is true of the empty string in Oracle in general). For those of us writing queries to be shared between Oracle and PG, Oracle-compatible bindvar emulation is a virtue. But if it's an issue for the original poster, he shouldn't use the feature. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 5, 2009, at 5:13 PM, Tom Jackson wrote: On Sat, Dec 5, 2009 at 8:37 AM, Don Baccus dhog...@pacifier.com wrote: On Dec 4, 2009, at 12:03 PM, Tom Jackson wrote: The problem remains for other databases using the ns_db APIs. The quoting examples are general, but don't always work. The person's using PG so a PG-specific solution solves the problem. No reason to make this more complex when a simple solution suffices. Really? The title of the post says AOLserver is vulnerable. The example code uses [ns_db]. In case anyone else is interested, you can avoid SQL injection without using bind variables, regardless of which database or driver you use. Another problem is working with nulls. You can't quote null and postgresql distinguishes the empty string from null. Tcl doesn't implement the null concept. 'set foo ' sets foo to the empty string, not null. Tcl can write a query string which uses the keyword NULL. Unfortunately the simple (but very nice and also safe) bind variable concept doesn't handle this common requirement. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 4, 2009, at 8:00 AM, bthj wrote: In a previous discussion thread here (ns_db and bind variable support) I see ns_db prepare... mentioned. Is that a safer way to perform db queries in adp pages? Just use the bind variable emulation ... select * from foo where id = :id rather than $id. SQL smuggling fears gone forever ... Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 4, 2009, at 10:29 AM, Jeff Rogers wrote: Unfortunately the postgres driver doesn't protect against against dml injection. The bind variable emulation does. It essentially does the quoting that an earlier poster recommended one do manually. No muss, no fuss... Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is this vulnerable to sql injection?
On Dec 4, 2009, at 3:15 PM, iuri de araujo sampaio wrote: reading the last discussion ... aside the magic words from Don to just change $id to :id that would solve the issue and the nice and very conceptual answer from jeff i tried to play a bit in attempt to understand and and practice the sqlinjection stuff I tried to run the following tcl script set id 1456 set sql_query select * from acs_objects where object_id = :id set db [ns_db gethandle] set selection [ns_db select $db $sql_query] ns_db getrow $db $selection but i got an error at [ns_db gethandle] i ran the scripts from tcl page within directory www how do i fix it? Since you're doing this in an openacs instance, use the openacs db_* API. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver templating options
Hossein Sharifi wrote: Hey all, What's the current state of templating systems in AOLserver? I've found two: 1) ATS: Is it well-maintained, and can it be easily used outside of an OpenACS installation? It was originally developed to be used with a standalone CMS built by ars digita people in the bay area, and later adapted to work with aD's ACS (which evolved into OpenACS). Breaking it out to run standalone again shouldn't be that difficult. There are hook into our localization (message catalog) stuff but that could be ignored/ripped out. The ATS supports master templates that appear to be much like the ADP Master Pages mentioned by Jeff (so i guess the similar MS technology referenced by that site), and has done so since oh 1998, 1999. Actually it's a hierarchy of master templates with the top of the hierarchy being the master for the entire site. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] is it necessary
On Oct 15, 2009, at 10:04 AM, nitin chandra wrote: Hi Everyone, Is it necessary to install OpenACS along with AoLserver? No, OpenACS is just a web toolkit that uses AOLserver, just as Django uses Apache. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] segfaults problems are solved
On Mar 2, 2009, at 9:30 AM, Alexey Pechnikov wrote: Hello! I did build debian package with AOL 4.5.1 and did find a lot of problems are fixed in this AOL version and other problems are produced by incorrect debian lenny package of AOL server. Thank for all comments. You can get these packages from my repository. If you can find out who the debian maintainers for these packages are, would you mind telling them that the packages can be fixed by properly compiling them? I don't know if the maintainers are on the AOLserver list. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOL + SQLite+nsproxy question
On Mar 1, 2009, at 9:21 AM, Tom Jackson wrote: On your datatype problem below, what is the problem? Why would you care about such a failure? And why not ask on a postgreSQL list, or a debian list when you have problems with their software? Tom ... chill. He just mentioned a datatype problem in passing, to explain his use of PG 8.1 not 8.3. I asked what datatype problem? out of curiousity, and he answered. Chill. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOL + SQLite+nsproxy question
On Mar 1, 2009, at 9:45 AM, Alexey Pechnikov wrote: nspostgres doesn't work as you can see Huh. Tell that to those of us using it w/o problems. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOL + SQLite+nsproxy question
On Mar 1, 2009, at 9:45 AM, Alexey Pechnikov wrote: http://www.google.com/search?hl=enq=nspostgres+received+fatal +signal+11btnG=Search nspostgres doesn't work as you can see. I know for a fact that Iuri, the last person who shows up for that search, got it working and in fact has used it in a development project in which I was mentoring him. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOL + SQLite+nsproxy question
On Feb 28, 2009, at 3:59 PM, Jeff Rogers wrote:
Alexey Pechnikov wrote:
I did try to use nssqlite module but get segmentation fault errors.
In AOL server 4.0.10
# tail -f /var/log/aolserver4/offline.sid.mobigroup.ru.log
“db_foreach “select value from session” {
alloc: invalid block: 0xb4cf5378: 78 b4 20
AOL server 4.5 doesn't work with PostgreSQL (nspostgres module
produce segmentation faults of AOL) and I can't use this. I did
read code nspostgres and didn't find any problems... but this code
doesn't work. I'm work with PostgreSQL 8.1 because PostgreSQL 8.3
in debian lenny has datatype errors.
Did you rebuild nspostgres against 4.5 (or better yet, cvs HEAD)?
I'm fairly certain that I've used nspostgres with 4.5.
nspostgres works fine with both aolserver 4.0.10 and 4.5. It's used
in production at education sites with tens of thousands of users
running aolserver/postgres-based e-learning software.
So Jeff's suggestion of rebuilding against 4.5 is a good one.
What kind of datatype errors are you getting in PG 8.3 in debian
lenny? I use PG 8.3 w/o problems, but must admit I've built mine from
source.
Don Baccus
http://donb.photo.net
http://birdnotes.net
http://openacs.org
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Data corruption with fastpath caching
On Aug 21, 2008, at 8:14 AM, Dossy Shiobara wrote: I've remained silent on this issue because I didn't want to be accused of stifling the community, etc. ... End of discussion. Accused. Guilty. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Custom server error page crash
On Jul 10, 2008, at 4:15 AM, William Scott Jordan wrote: Hey all! I've recently added a custom server error message using a redirect in AOLserver's config file. Since then, I've been occasionally seeing the following error in the logs: [09/Jul/2008:18:04:08][30505.1690512][-conn:1-] Error: return: failed to redirect 'PROPFIND /500.html': exceeded recursion limit of 3 I've seen the exceeded recursion limit error when the server receives WebDAV operators and no filter is registered to handle them. There are bots out there that probe sites ... Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Custom server error page crash
On Jul 10, 2008, at 11:44 AM, Fenton, Brian wrote: Hi Scott, Exactly how did you add the custom error page? And do you know what PROPFIND refers to? As I said earlier, probing by WebDAV ops causes this error ... and googling PROPFIND yields, unsurprisingly: The WebDAVPROPFIND Method retrieves properties for a resource identified by the request Uniform Resource Identifier (URI). The PROPFIND Method can be used on collection and property resources. 4.01 didn't die with this. 4.10 + does AFAIK Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Custom server error page crash
On Jul 10, 2008, at 6:25 PM, Tom Jackson wrote: Is anything registered to handle the PROPFIND method? I'm just guessing that could be part of the problem. Also, does /500.html exist? The problem comes about when *nothing* is registered for these methods. I've known this for quite a long time but have never tried tracking it down internally within AOLserver. Be nice if someone wanted to do that ... Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tcl variables
On Apr 21, 2008, at 2:45 AM, Xavier Bourguignon wrote: Don and everybody else know I have no programming experience what so ever, I wrote that I am a noob, why does he go asking about my programming background for? Because, of course, I thought you meant that you were new to the AOLserver/Tcl world. Not programming altogether. Keep digging that hole deeper, dude. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tcl variables
On Apr 21, 2008, at 7:00 AM, Tom Jackson wrote: What is baffling is how, if you know no other languages, how you got AOLserver installed? Actually, I'm quite impressed he got as far as he did without any help ... congrats to xavier for that. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] apology
On Apr 21, 2008, at 7:23 AM, Xavier Bourguignon wrote: Sorry all. Apology accepted, no problem. Thank you. I suppose I won't be welcome here anymore Oh, c'mon, this is a fairly small list and I don't know of anyone here who won't accept an honest apology. Now that we know you're new to programming, as well as our own small corner of the programming universe, I'm sure people will be happy to help you. Though some of that help may come in the form of ... you should really read this .. etc. Actually my first recommendation is to do what I did when I taught myself programming back in (oh lord) 1971 - read programs and figure out how they work, and ask questions if there's something you read that you don't understand. And play and experiment, too. If you're already doing this, please don't be offended my by recommending you do what you're already doing, though, OK? Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tcl variables
On Apr 20, 2008, at 2:48 AM, Xavier Bourguignon wrote: So Bob, what is the difference between setting the variable within the adp and setting it in a procedure? Local variables within a procedure are ... local. This is basic - what's your programming background? Surely the variable set in the procedure should be available as the procedure is called within the adp. Ummm ... again, what's your programming background? Why would you expect a local variable to be available globally? Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tcl variables
On Apr 20, 2008, at 11:20 AM, Xavier Bourguignon wrote: Don, my programming background has nothing to do with the questions I asked, so sorry, you won't get an answer from me, but thank you for trying. I asked because more information about your knowledge and skills can help us answer you more effectively. But apparently you found my asking to be offensive. Oh, well. I won't bother trying to answer other questions you might have. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] tcl variables
On Apr 20, 2008, at 1:13 PM, Xavier Bourguignon wrote: It is so great knowing I won't get any more nasty comments from you. I wasn't trying to be nasty, and I'm sorry you took it that way, but I have to say, after my taking the time to explain why I asked about your level of programming experience, your response is most ungracious. You're being an asshole, frankly. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver and Pgtcl
On Apr 16, 2008, at 2:33 PM, Tom Jackson wrote: You should look at the pg driver, I think it can emulate bind variables, or maybe it is part of the db_* API of OpenACS. You have to compile nspostgres.c for OpenACS use to make the command available. Then use ns_pg_bind rather than ns_db. :foo will reference the tcl var foo in the caller. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver and Pgtcl
On Apr 16, 2008, at 3:44 PM, Dossy Shiobara wrote: I have wanted to add bind variable support to nsdb for a _long_ time, but never got around to computing this support matrix that I describe above. If you do, it needs to be a config option, because with Oracle you do *not* want to do this in ns_db. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver and Pgtcl
On Apr 16, 2008, at 4:20 PM, Bas Scheffers wrote: On 17/04/2008, at 8:14 AM, Dossy Shiobara wrote: I have wanted to add bind variable support to nsdb for a _long_ time, but never got around to computing this support matrix that I describe above. I don't really like bind variables, I would much rather see it implemented like: ns_db select $db select * from people where country = $1 and age $2 [list au 25] Geez, names are more readable than numbers in any sizable query. nspostgres supports the optional passing of an ns_set to define the bind vars, and the openacs db api will convert an array get list to the ns_set for you. And the default bind var syntax is just damned convenient, why force more work than is necessary on the part of the person writing queries? And before answering well, they can always use the variable directly remember that both emulated and real bind vars give protect against sql smuggling. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_db and bind variable support
On Apr 16, 2008, at 8:48 PM, Jeff Rogers wrote: I've been told this by every oracle dba I've worked with and the performance gains I've seen by moving to prepared statements is generally quite small unless the sql is horrendously complex, and even then the backends appear to do caching of query plans anyway and so essentially use prepared queries implicitly even when the application code doesn't. sqlite even throws particular errors when something happens to invalidate its cached query plans. True of Oracle, not true, for instance, of Postgres. However, parsing of a SQL statement's extremely fast (how often are queries longer than a couple dozen lines in your typical web app?), what needs caching is the execution plan generated query optimizer. However, that can be a bit dicey unless your data's nicely distributed and you can have confidence that one plan will work about as well as any other the optimizer might generate, and that the very first query happens to generate such a plan. And that you gather analyzer stats and clear the query plan cache fairly often ... Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 13, 2008, at 1:48 AM, 'Jesus' Jeff Rogers wrote: Tying in with a different thread, my suggestion for an improvement would be to ship AOLserver should with (or alongside) a standard/ sample library that is intended to be looked at and tweaked (the standard library that ships currently is boilerplate). This standard library could include a filter proc to call 'ns_conn gzip 1' (or however it is exposed at the tcl level) based on the config file setting. Just do it right in the first place. The config file approach would solve 99% of the need, and for those needing explicit control an explicit call to ns_return_compress or whatever would give it to them. Whatever happened to the KISS principle? One of the things I love about AOLserver is its relative simplicity. People always seem to want to screw with that for some reason. Another thing to include in this standard library could be compatibility code for the old thread configuration directives mapping them onto the new 4.5 thread configuration commands. Or just put back the config parameters as they were, they worked fine for everyone for a decade. I don't remember the masses shouting that the config approach wasn't sufficient. It suddenly appeared without discussion nor documentation. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 13, 2008, at 5:14 AM, Dossy Shiobara wrote: Uh, either your memory is poor or you need to review the mailing list archives again. Just did, and apparently the search functionality on the archives has a poor memory, too. Seriously, this has been a long-standing ask, to make more config settings modifiable at runtime. Seriously, I've been on this list and part of the community for about a decade, and, no, there have been very few such requests. Can you point to even one such request this year, for instance? Perhaps the way compression has been implemented wasn't perfect, but it was a start, and I think Jeff's suggestion of shipping a filter proc that enables compression server-wide by default is the right answer. Making the setting purely config-driven is just perpetuating the sorry, config settings need restarts problem. People who want can use an explicit call to ns_returnz or whatever one wants to call it. Make the 99% case work easily. Don't be different than apache just because you want to be different. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 9:40 PM, Dossy Shiobara wrote: On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): I just want to remind folks that Apache's design is config-driven by necessity, not by intentional design. So? It's still the right thing to do in this case. I agree with Brett's proposal. In AOLserver, we DO have the benefit of being able to interact with the server from application code. This allows us to design and implement things better than in Apache Or worse. I hope it will result in a better solution than what's currently available in Apache. I think you meant to say different ... and simply being different is no reason to reject a perfectly good solution to the problem. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:41 PM, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. You could allow control by mime-type and size, though I'd say all but the shortest text/* files would benefit. And the Yahoo best practices page referenced earlier suggests that ALL text/* files will benefit, on average. Computers are actually quite fast these days, and while dial-up connections are becoming increasingly rare, the fact is that there are bandwidth bottlenecks that slow the pace at which bits are transmitted from your server to the user's browser. You could also have an explicit ns_returnz for those who want finer- grained control - leave compression off in your configuration file and explicitly request it if you want it. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) This is more micromanaging of delivery that's really required, IMO. Mostly you just want to make sure that only text/* or other uncompressed formats are compressed. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compiling 4.5 on Mac OS X 10.5 leopard issues
On Mar 22, 2008, at 6:04 AM, Mark Aufflick wrote: Thread 0 Crashed: 0 libSystem.B.dylib 0x93e7d0c8 strlen + 8 This is the 64-bit vs. 32-bit aolserver vs tcl problem people have mentioned in regard to 4.0.10 and 4.5 (4.0.1 compiles out of the box). Someone who has this working might want to post it up on the wiki, and we'll probably want to post the solution on the openacs wiki, too. My understanding is that compiling tcl with 64 bit enabled solves the problem, but haven't followed too closely because 1) my recent purchase of a macbook pro was a bit spontaneous due to the version that was current about 4 weeks ago showing up refurbished for $1450 (they still have some left, last time I looked) , I'd ignored the problem before 'cause I was running a G4 powerbook and 2) I've been running 4.0.1 on my development machines anyway, being too lazy to upgrade, and our production machines are running 4.0.10 but under 32- bit linux. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] globals
On Mar 19, 2008, at 3:21 PM, Xavier Bourguignon wrote: Hi, Is there a way to set a global which stays in memory for the life of the server and not just for the life of a request? nsv_* -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] how do I
On Mar 19, 2008, at 8:08 PM, Robert Seeger wrote: I've never been fond of the fact that AOLServer has no internal redirect mechanism. You can implement your own, in Tcl. We have one in OpenACS, but it's tied slightly to our way of mapping URLs to paths, and our template engine. But conceptually, it's simple and yes, useful, we use it in many places within the toolkit. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] how do I
On Mar 18, 2008, at 11:25 AM, Xavier Bourguignon wrote: I have a URL mapped to a Tcl procedure like this: ns_register_proc POST /login login in my adp page called index.adp I have this: form action =/login method=post username: input type=text name=usernamebr password: input type=password name=passwordbr input type=submit name=submit value=Login /form In one of my Tcl file, I have a procedure called login. This procedure gets called once the submit button is clicked. This procedure gets the username and password from the form and processese them to check that the username/password combination exists in the database. If it does then I want to show the menu.adp page, if not, I want to show the index.adp page again. Look here: http://panoptic.com/wiki/aolserver/Ns_returnredirect ns_returnredirect foo tells the browser to redirect to the URL foo -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] how do I
On Mar 18, 2008, at 12:26 PM, Xavier Bourguignon wrote:
Ok, but what do I do if they do exist? How do I say to aolserver that
I want to serve the menu.adp file?
If { ...login ok ... } {
ns_returnredirect someplace-interesting
}
Maybe I'm missing something ...
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] how do I
On Mar 18, 2008, at 12:39 PM, Xavier Bourguignon wrote: Thanks Don and Darren, I will look at the info. I just find it strange that I have to REDIRECT to another url, to me redirect means to go away from the current context to go to another, usually another domain, but i may be wrong and my understanding needs to be revised. You're just telling the browser to go to some URL -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] PostgreSQL near-lockups
On Tuesday 17 January 2006 09:05 pm, you wrote: Am I on the right track with the following? I think so, yes. The #1 question to answer is are the long-running threads caused by an application query, or something internal to Postgres? -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] PostgreSQL near-lockups
On Monday 16 January 2006 08:17 pm, Dave Siktberg wrote: Thanks! I do use svc -t when restarting, so I will try -k and observe what happens. I'll also now look more carefully at the logs -- I think there are some clues I haven't yet picked up. Enable PG logging and examine those logs, as well. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Support for non-HTTP protocols
On Tuesday 17 August 2004 10:17 am, Zoran Vasiljevic wrote: b. NO, I do not need AS doing anything else than http and am perfectly happy with status-quo now. Just forget the whole thing. This is my vote. Let's keep things simple and let's keep things working. Why is this even on the table when people using OpenSSL can't run AOLserver 4 in a production environment? -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Support for non-HTTP protocols
On Tuesday 17 August 2004 10:59 am, Zoran Vasiljevic wrote: Why is this on the table? Because there are people looking for this kind of functionality and because two of them invested great deal of time to get it working for themselves. And, they posted a RFE and are willing to share their work. Fine. But there's no reason to push forward on this immediately. Resources are finite, triage and prioritization are important, and we have definite breakage in the current supposedly stable release - OpenSSL is crucial to any commercial usage for e-commerce or any environment where sensitive information is passed to or taken from the user's browser. And, yes, I realize OpenSSL isn't part of the AOLserver core proper, but it's importance is such that it might as well be. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Support for non-HTTP protocols
On Tuesday 17 August 2004 11:51 am, Dossy Shiobara wrote: Janine has offered to help, but cannot provide access to her production environments where the problem is occurring. Sloan's going to try to reproduce it in the next week or two, at which time I plan to dig around in gdb ... -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLSERVER Digest - 10 Aug 2004 to 11 Aug 2004 (#2004-171)
On Friday 13 August 2004 09:22 am, Dossy Shiobara wrote: We're talking web applications here that consist of a collection of web pages. That's so simple, why overcomplicate things with a whole templating system? If folks want to punish themselves by requiring an ADP and Tcl page, that's fine. I certainly wouldn't encourage that behavior ... unless someone can give me a real example with code why it's actually superior, as opposed to the way ACS has always done it. You've got it backwards, that's NOT the way ACS has always done it. Previous versions of the ACS intermingled logic and presentation. Experience working with client non-programmer designers that led ArsDigita to decide to write a templating system that allows for the separation of logic and presentation. We're not the only people in the world who see value in this. You write all your web pages by hand. Fine. When I want to change the look and feel of every form in an OpenACS site, to meet the design criteria of a client, I change one file and the templating system takes care of the rest. It's a bit less work than visiting every .adp page in the system looking for form tags... -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLSERVER Digest - 10 Aug 2004 to 11 Aug 2004 (#2004-171)
On Friday 13 August 2004 12:43 pm, Andrew Piskorski wrote: In the case of the OpenACS Templating System (and in all versions of ACS back to somewhere around ACS 3.4 or so), the .tcl pages are in fact compiled to Tcl procs and cached on first use, which eliminates any performance difference between the two places Tcl code can live. Actually the .adp page is compiled to Tcl, appended to the script in the .tcl file, compiled, and the bytecode cached. There's a one-time compile penalty per interpreter. It would be nice if some of the really handy page-oriented OpenACS procs, like ad_page_contract, ALSO worked the same way for procedures. It would also be nice if the Templating System implemenation could be cleaned up a bit and made easier to hack on. These are, however, quite minor complaints, and never bothered me much back when I was using the Templating System on a regular basis. Also, some of them have even been partially addressed already, e.g.: Originally the templating system was standalone... -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Officially dropping support for nsxml?
On Friday 02 July 2004 10:12 am, Dossy wrote: There are currently 3 open bugs in SourceForge for nsxml: #749796, #749789 and #749774. However, as far as I know, nsxml has been deprecated in favor of using tDOM with AOLserver. The OpenACS project no longer uses nsxml, just tDOM, for our current releases. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Other languages in AOLserver (was: ANN: New project leader for AOLserver)
On Friday 21 May 2004 02:19 am, you wrote: Bernd Eidenschink said: supporting PHP would be absolutely no harm. I would think of it as the Not necesarily. Nothing can harm any product like not having a focus. Instead of giving what most of us here believe are inferior solutions the finger, supporting too many technologies may make AOLserver look like a pathetic wannabe. Very, very true. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] OpenMSG software
On Saturday 22 November 2003 10:15 am, you wrote: Does anybody know what happend to www.open-msg.com? I looking for source code released as GPL by OpenMSG Ltd (as stated on version found at http://web.archive.org/web/20021124025856/http://www.open-msg.net/) - OpenMSG release S-Moker V1.0 as Open Source. I would also like to contact Simon Millward, but it's address @open-msg.com is probably not valid. OpenMSG folded ... I don't know where a copy of the software might be found. It's a pity, they won a UK SMS messaging industry award a year or so back. Simon posted recently on the general openacs.org QA forum, in the last two weeks. If you want to visit our site and poke through old messages you'll find his e-mail address. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Selecting an empty (null) oracle-clob crashes AOLserver on Linux
On Tuesday 11 November 2003 08:24 pm, Seena Kasmai wrote: There has been a suggestion as to upgrade the Oracle client on the Linux to 9.2.0.2, any comments on that would also be appreciated. As I pointed out in the OpenACS forum this is a known bug in Oracle, has nothing to do with AOLserver per se (just the Oracle client library) ... if you have purchased Oracle support you should be able to find out the exact version which fixes this. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] External Interbase/Firebird Driver?
On Monday 10 November 2003 05:12 pm, Nathan Seven wrote: Well, like I said- I'm new to AOLServer so I'm going off of the tuning docs: http://www.aolserver.com/docs/admin/dbadmin.html Speaking of external drivers: It is likely, however, that this distributed approach, i.e. a separate process per database connection, will improve overall database throughput, even with the additional communication overhead. We expect this performance improvement because vendor-supplied database client libraries, running within a multi-threaded server, must limit concurrency via resource locks. This is an ancient document wow ... AFAIK there's no evidence that this hypothetical statement has proven to be true for either the Oracle or PostgreSQL client library. And when the proxy daemon driver was first introduced that additional communication overhead mentioned above turned out to be horrendous, though it got greatly speeded up soon after that discovery. I remember because I'm the one who flagged that fact when comparing throughput of that driver + Sybase vs. the internal driver and Oracle. Long time ago ... I'm using FreeBSD as my OS, and it's got several threading models. The sane one will not distribute threads to different CPUs (eliminating any gain from SMP). The 1-1 thread-proc model and the KSE model are both new to 5.x, which I'm a little hesitant to use... So- if I end up going with stable-FreeBSD, all SMP value will be lost unless I can break the DB stuff in to different procs (vs different threads). Ummm ... your database is a separate process, it's just the driver that's going to run in the threaded environment. PostgreSQL spawns a new process for each connection so FreeBSD should make fine use of both processors. Generally you'll be asking AOLserver to initiate several connections and pool them, which means several backend processes in the PG case. Much, much more time is spent in the RDBMS than in the driver or PG client library. This combined with the fact that each PG backend runs in a separate process is why the hypothetical argument above is bogus for PG and always has been. My experience with either is limited and they *are* pretty feature-comparable, but the specific advantages that made me choose Firebird over Postgresql are these: Shadow-db functionality. This is a good point. SPs without linked-in-interpreters. (less code to have to trust) PL/pgSQL is trustworthy, I'd describe this as a bogus reason in practice (being a very experienced PG person). Simpler administration. (for me anyway) What do you think is simpler? The main issue with PG is having to run a VACUUM job to recover old tuples - Interbase does this automatically (they both use the same multigenerational, non-overwriting approach to tuple storage, unlike Sybase or Oracle which use overwriting storage managers). I just ns_sched a Tcl proc that does the VACUUM once a night and having done that ... there's no administration involved unless you've got a rapidly growing database that requires you watch disk space etc. And well- it just leaves a little more robust of a taste in my mouth, Interbase is likely the largest-deployed-db on the planet. PG's gotten extremely good in the last three-four years. There's far more active development than with Interbase - which in a way is an argument supporting your good feelings. i.e. Interbase is solid and not changing much, PG is solid but each version adds a bunch of new functionality that could in theory make it less stable until it is better tested, though in practice this has not been the case. Still, I generally run a version or so behind the latest release with PostgreSQL just to let other people verify new versions are stable. Another major feature missing from PG is some form of tablespace concept that lets you put indexes and tables on different filesystems (in general, different disk spindles) which can help performance. That will be coming in a few months. At the moment you're stuck using the Unix ln -s command to manage where things are placed if you need to. On the other hand, with today's huge cheap disks and insanely cheap RAM I've never had to do that in practice. Unless you're looking at 100s of megabytes of stuff I'd say forget I even raised this issue (and I don't know if InterBase implements tablespaces or their equivalent anyway). But- like I said, the differences between both are minor, so if I had to use Postgresql, I could. Try it ... I think you'll like it. The PG lists are very helpful, and for AOLserver + PG issues both this list and the forums over at our OpenACS project are full of people who use the two together day in and day out, for paying client websites. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER
Re: [AOLSERVER] Oracle 9i
On Wednesday 17 September 2003 12:45 pm, Barry Books wrote: I'm moving an ACS site to 9i and Aolserver 4.0. I've built nsoracle-2.6 and linked with the oci9 libs and I started getting this in my logs. It appears from the Oracle site there is a change in the drivers that requires initilizing bind variables. I'm assuming this requires a driver change. Does anyone have a patch? Try asking on our OpenACS site - a couple of folks have been moving the toolkit to Oracle 9i and have it working, and haven't mentioned any driver change being necessary ... -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] stored procs and AOLServer
On Tuesday 26 August 2003 05:41 pm, Dossy wrote: On 2003.08.26, Roberto Mello [EMAIL PROTECTED] wrote: OpenACS and its database API (which builds upon AOLserver's API) has code to do that, including returning a list of ns_sets. http://openacs.org/api-doc/proc-view?proc=db%5flist%5fof%5fns%5fsets I looked at nsoracle 2.6 and it doesn't seem to have any support for REF CURSORs ... what Oracle driver is OpenACS using? The docs at the URL you provided don't mention supporting the sql parameter being a stored proc exec, but it doesn't mention it not supporting it, either. The driver doesn't handle cursors but doesn't Oracle 9i allow for PL/SQL functions that return rowsets? The driver should be able to handle that case fine. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] compiling postgresql driver on os x
On Friday 18 July 2003 11:32 am, derek wrote: I'm running mac os 10.2.6 and postgresql 7.3.3. I've tried compiling the nspostgres driver from aolserver and the postgres driver from openacs -- both fail. Are they compatible with 7.3.3? Are you sure you've got the include paths right? I've compiled it for 10.2.6 and PG 7.3.2, 7.3.3 is not a major change so it should work. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver failure under load test on Mac OS X?
On Monday 30 June 2003 09:00 am, Kevin Murphy wrote: I have been testing apache 1.3.27, webstar 5.?, and aolserver 3.5.6 4.0B8 with ab and http_load on Mac OS X 10.2.5. I have noticed that when I raise the concurrent requests much above 12, ab and http_load both indicate lots of errors for aolserver: connection reset by peer or byte count wrong (mostly the latter). Webstar fails in a similar pattern when around 40 concurrent requests. Apache is fine up to around 200. I have made dozens of trials, and the results are consistent. Have you tried the threaded version of Apache? I'm just digging into OS X (a client just gifted me a 17 powerbook) and 10.2.6 claims a better pthread implementation. The notes make it sound like it's more complete, not more robust, but perhaps robustness has been a bit of an issue thus far? Just a guess on my end. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nspostgres driver problem?
On Friday 27 June 2003 02:47 pm, you wrote: Hello All, I have an AOLserver installed on NetBSD-current with Zoran's help. It works fine but I can't connect to a postgres database. The PostgreSQL version is 7.3.3, the AOLserver version is 4b8, the nspostgres driver version is 4.0-beta1. After the server startup it gives the following messages (with embedded fprintf functions for traceing in the nsdb/dbinit.c file): Well ... it's not that the driver can't connect to the database, but rather it's the fact that for some reason the driver's not been loaded at all. Have you defined nspostgres.so in your database drivers section? Like this? ns_section ns/db/drivers ns_parampostgres nspostgres.so ns_section ns/db/pool/pool1 ns_param Driver postgres -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Saturday 07 June 2003 09:59 am, Zoran Vasiljevic wrote: On Friday 06 June 2003 17:35, Don Baccus wrote: Right, if you skip the traces you don't get the module-defined ns_* commands, we're on the same page here ... as far as this bit goes anyway. After thinking again and again, I see two possible scenarios. One thing upfront: I'd like to have *both* of the ns_eval behaviours available: the older one (as in 3.x) and the new interp sync mode. This is my target. I agree ... Well, either of those will lead to solution. The second option allows for more flexibility. The first is simpler to implement. Thoughts? I don't have strong feelings either way. Synching of the state of all interpreters is something that won't be done often and requires great care in how you write the rest of your application so I don't think we need the command to be particularly aesthetic, elegant etc. The second approach is more flexible so is attractive but I don't think there's a lot of demand for the extra functionality. Then again if you implement it the masses may suddenly start wondering how they ever lived without it in earlier versions of AOLserver! Who knows? :) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Friday 06 June 2003 02:53 am, Zoran Vasiljevic wrote: On Friday 06 June 2003 11:48, you wrote: Zoran Vasiljevic wrote: I would love to hear some other oppinions. But, I'm already thinking about what we'd need to do so that both approaches are available. My simple guess would be that the easiest solution would be to 1/ create a temporary interpreter 2/ eval the initialization code in it 3/ eval the code entered in ns_eval 4/ grab the new initialization code Good point :) Zoran Yes, this would be an easy spin-off of the existing code I believe. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Friday 06 June 2003 08:15 am, Zoran Vasiljevic wrote:
My initial idea was to simply make the Nsd as static package by doing
Tcl_StaticPackage() at the end of InitInterp() and then do from Tcl:
set interp [interp create]
$interp eval {load Nsd}
$interp eval [ns_ictl get]
and so on... but this won't get the proper virtual server context
so it'll skip the traces. Phew. I must dig little bit more there.
Right, if you skip the traces you don't get the module-defined ns_* commands,
we're on the same page here ... as far as this bit goes anyway.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Friday 06 June 2003 08:12 am, Lamar Owen wrote: On Thursday 05 June 2003 22:28, Don Baccus wrote: The implementation in AOLserver 4 is very, very different. The script is executed then the ENTIRE set of namespaces and procs are saved to the server's tcl.script pointer. Argh! One EVIL side effect of this is that some of the standard ns_* Tcl API is implemented in Tcl, in some cases using global variables. So, for instance, I have a test case in which the following code: The other side effect (that we've been seeing complained about lately) is related to the following in acs-tcl I didn't bother mentioning these because I thought pointing out the problem with ns_getform would get people's attention :) I'd kludged around some of these by initializing them in the request processor before I figured out that our two calls to ns_evil were the problem. Methinks this could have bad side-effects, particularly if a thread without a pool and without handles executes ns_eval. The next invocation of any of the db_* API could produce the uninitialized pool result 'nsdb0' (I knew I remembered that from somewhere -- I've seen the nsdb0 result before when a pool wasn't properly initialized (way back when the PostgreSQL driver was being beta tested for PostgreSQL 6.2.1, and AOLserver was at 2.2)). This was the first problem I ran into, indeed, after kludging around it I ran into the ns_getform problem and decided to start reading AOLserver sources since I had no idea that ns_eval was the problem ... But this behavior of ns_eval could explain that problem, depending upon the timing of its execution, as well as where the ns_eval was used. Yes, I believe you'll find that this is the problem. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Friday 06 June 2003 11:54 am, Vinod Kurup wrote: On Fri, 6 Jun 2003 11:12:43 -0400, Lamar Owen wrote: So, when a patch for OpenACS that doesn't use ns_eval is ready, those of you who have problems with the nsdb0 stuff, if yu could please determine whether the elimination of ns_eval fixes it. I made a patch http://openacs.org/bugtracker/openacs/patch?patch_number=165 and it gets rid of the nsdb0 problem for me and at least a few others who have emailed me. Hey, sweet, Vinod! Great doctoring of the code there! (for those of you not part of the OpenACS community, Vinod is a practicing MD. Isn't Open Source great?) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
[AOLSERVER] Net access for patients ...
On Friday 06 June 2003 06:13 pm, you wrote: On Friday, June 6, 2003, at 05:42 PM, Don Baccus wrote: (for those of you not part of the OpenACS community, Vinod is a practicing MD. Isn't Open Source great?) Open Source definitely is great. I can't wait for the day that my patients come with error logs and gdb-hook-ups. Then my 2 worlds will be 1 and I'll be very happy. ;-) A guy I know - a research biochemist who is very fit and in his mid-fifties but has been having episodes of skipping heart beats, racing etc - was given a really cool device by OHSU, our local med school. They were unable to trigger any episodes when he was there in person, on the treadmill, etc so he triggers this device whenever he has an episode, then goes to the phone and uploads the data over a modem. Pretty cool! -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Net access for patients ...
On Friday 06 June 2003 06:27 pm, you wrote: A guy I know - a research biochemist who is very fit and in his mid-fifties but has been having episodes of skipping heart beats, racing etc - was given a really cool device by OHSU, our local med school. Sorry I meant to e-mail that to Vinod personally, not the list! :( -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4
On Thursday 05 June 2003 07:36 pm, Nathan Folkman wrote:
We could rename the command to be ns_evil. :-)
You've got my vote!
Actually ... as currently implemented it would probably be better to just
rename it ns_synch or the like.
global foo
set foo bar
ns_eval {}
is equivalent to
ns_eval {
global foo
set foo bar
}
In that both whomp on your entire global space and foo is available and set
to bar in both cases to other interps.
Just to shortcut you a bit, ns_eval is now in nsd/init.tcl where it calls
_save_namespaces:
proc ns_eval {args} {
set len [llength $args]
if {$len == 0} {
return
} elseif {$len == 1} {
set args [lindex $args 0]
}
set code [catch {uplevel 1 $args} result]
if {$code == 1} {
# TCL_ERROR: Dump this interp to avoid proc pollution.
ns_markfordelete
} else {
# Save this interp's namespaces for others.
_ns_savenamespaces
}
return -code $code $result
}
The old code first evaluated the script to make sure there were no errors then
set things up so other interps would run it ASAP.
I can see why the current approach is used ... there might be any number of
ns_evals run before the next update of an interp is done in the current
scheme. Without immediately evaluating the script in all interps (so it can
be tossed and later replaced by the script attached to later ns_eval calls)
it's hard to see how the old semantics can be maintained.
Maybe it's just a bad idea and people should use nsvs that have proper locking
etc. ns_eval could log a bold warning saying I'm EVIL don't use me! and I
wouldn't care :)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
[AOLSERVER] ns_eval is EVIL in AOLserver 4
Here's the documentation on the aolserver.com website, which describes how it
works in AOLserver 3:
ns_eval evaluates the Tcl passed in to this function. The Tcl is evaluated in
all the Tcl interpreters for this virtual server. You can use this command to
maintain global variables. For example, if you execute:
ns_eval set g 1
in one interpreter, later operations will see $g equal to 1 no matter what
interpreter they are assigned to.
The implementation in AOLserver 4 is very, very different. The script is
executed then the ENTIRE set of namespaces and procs are saved to the
server's tcl.script pointer.
This means that when interpreters are updated (as happens when an
interpreter's created for a new thread, for instance) ALL of the global
variables in the new thread have the values in the old thread. ns_eval {
...script ... } , then, is really a synch all interpreters command that
first evaluates the given script.
One EVIL side effect of this is that some of the standard ns_* Tcl API is
implemented in Tcl, in some cases using global variables. So, for instance,
I have a test case in which the following code:
set form_size [ns_set size [ns_getform]]
fails because another script has done an ns_eval and _ns_form was set in that
thread to t3. In the failing thread [ns_getform] has never been called,
yet it's seeing _ns_form with the value t3 - an ns_set which does not exist
in its context, of course.
This is ... non-intuitive. Especially if one RTFMs and expects the behavior
to be at least someone like the behavior that's described ...
Now the one use of ns_eval in OpenACS that causes the above problem can be
fixed by simply switching to nsvs (probably a good idea anyway) but the
documentation for ns_eval should be changed, perhaps? I have a hard time
seeing the new functionality being all that useful ...
If I sound annoyed it's because I just spent about four hours tracking down
why one certain operation in OpenACS was causing ns_getform to fail after an
ns_returnredirect. On the bright side I've been through all of the
AOLserver thread code and the connection thread code so know all about how
thread init and create callbacks are registered and more stuff than I even
want to think about at the moment ...
And there are only two ns_evals in the entire OpenACS toolkit and they'll be
easy to get rid of.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
Zoran Vasiljevic wrote: For all you Mac OSX users out there... The Tcl8.4.x uses the OS-call realpath() to figure-out the real physical path of the file on the filesystem, stripped of all ./, ../, constructs, symlinks and alike. BANG: this function uses chdir/fchdir internally which changes the process current working directory for each invocation. It is called for just about *every* path you pass to the Tcl library! Wow! The funny thing: the man page does not care to mention this *important* side-effect! This is truly sick, Zoran. Truly sick. An extremely obnoxious side-effect, even if it were documented. Does Apple have a process for filing bug reports that would give us some hope one of their Unix hackers will see it? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
Rob Mayoff wrote: +-- On Mar 27, Zoran Vasiljevic said: Tcl. This solves this issue cleanly. The ultimate fix, of course, is to modify the Darwin realpath() to behave better. I wonder what you mean by behave better. Does realpath() leave the cwd changed? If I read him correctly it does leave the process cwd changed. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Best way for user authentication?
Bas Scheffers wrote: I don't see what is so hard about describing all your procedure in a way similar to Javadocs. Just because they're not on the openacs.org site (Dave, what's up with that?) doesn't mean they're not part of our toolkit! Download and install it and you'll see that the vast majority of procs *are* described in a way *very* similar to Javadocs. What we're missing are cookbook-ish style docs that set you through writing and customizing stuff. It's a catch 22 situation for the developers; developers don't like doing docs, but they want as many people as possible to use it. Traditionally we've been a very small team of volunteers. However over the last several months the team's been growing steadily and that includes a couple of people who have stepped up to work on documentation, in particular documentation to help people get started. We have several developers who don't mind doing docs, but that doesn't mean they always have time doing docs. While making our stuff available to as many people as possible is certainly a nice goal, for most of us our primary goal is to make sure we deliver working websites to our clients on time. Personaly, I would prefer a package that does not have and client-facing pages at all, only admin pages and a good API documentation. Wheels were made to be reinvented, true enough :) -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ADP: are if's possible?
Tom Jackson wrote: IANAL, but I wouldn't rely on a program to generate a legal document. Maybe a disclaimer somewhere written in plain ol' HTML would be a better solution. If you really want a page that breaks on a coding error, look at OpenACS's templating system, each 'adp' is actually compiled into a tcl script and executed. Someone's working on making the templating system and the OpenACS database API available as standalone libraries that will work directly with AOLserver. Not sure when this will be finished ... -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Zoran Vasiljevic wrote: On Saturday 15 March 2003 19:28, you wrote: Hmmm ... I added a bunch of typecasts to avoid warnings at compile time, are you saying you had to add more or that you've taken some out? Most were to cast int to size_t - the code uses size information as a signed integer in some places (-1 as a flag) so simply changing the offending vars to size_t caused new warnings to pop up. I just had to add a couple. OK ... it had compiled clean here but then again the version of gcc I was using was relatively ancient, I haven't updated my laptop in the three years I've had it. I would probably take the approach of adding a new command to ns_cache, using servPtr == NULL as a flag seems a bit of a kludge. Most of the code works on a cache pointer with no other context information, implementing a true global cache will just involve adding a new proc to use a static tcl hashtable to map the name to a cache pointer. You initializing that hashtable and an associated static lock the first time the module is loaded, and only the first time ... I see. Well, this is quite simple as well. I'll look into it and try to get it in the Tcl API as transparent as possible. Yes, it will be simple, if it weren't for the fact that the OpenACS project's taking 100% of my time at the moment I would be more than glad to finish up this last remaining piece. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Zoran Vasiljevic wrote: On Sunday 16 March 2003 15:18, Andrew Piskorski wrote: On Sun, Mar 16, 2003 at 02:33:53PM +0100, Zoran Vasiljevic wrote: ns_cache create name ?-size size? ?-timeout timeout? ?-thread boolean | -common boolean? The name of the new option -common is the best what came to my -serverwide? -global? -serverwide it is. I agree. -global would be confusing because of the existing terminology in the code and documentation. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Zoran Vasiljevic wrote: On Sunday 16 March 2003 16:14, you wrote: Yes, it will be simple, if it weren't for the fact that the OpenACS project's taking 100% of my time at the moment I would be more than glad to finish up this last remaining piece. Well, relax ;) The work is done, at least on the ns_cache. It is in the SF and I've made the 1.5 version in the Files section. The new option is set to -serverwide boolean if you ever need it. Thanks, Zoran! -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Jim Wilcoxson wrote: Are the changes such that a cache can be either per-virtual-server or per-server? It might be useful to retain the ability to have a server-wide cache. No, I didn't, my changes essentially maintain the old semantics on a per-virtual-server basis. It wouldn't be hard to add a server-wide cache but I don't personally have time to work on it and it's not something we need to virtual host multiple OpenACS sites. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Zoran Vasiljevic wrote: On Saturday 15 March 2003 16:12, Don Baccus wrote: So ... my questions are simple. Who maintains ns_cache these days? Who has commit rights to CVS? How do I get these modifications accepted? Should the maintainer (Rob?) review my changes? Don, Since I'm about to move about a dozen packages to 4.0 (we'll am just in the middle of it), I can take a look on your ns_cache changes as well. Just send me a tarball with your changed ns_cache version. I must also second Jim; we should really have a process-wide *in addition* to the per-vserver cache. I'm sure that would be nice, and if anyone has time to do it, they're more than welcome to do so. I don't, however, at the moment. My goal here was to simply maintain the existing semantics for site code written to run in the single server enivronment that's now being run in the multiple virtual server environment. In other words, existing site code shouldn't break, and code which uses the current nscache will break when multiple virtual servers are run. I did what I need for the OpenACS project and I have time for, unfortunately. I don't think the fact that the functionality's not been enhanced should cause us to hold back adopting my changes (assuming they pass inspection, etc) - existing code won't miss enhancements it doesn't know about. And I might find time later - in a couple of months - to add a true global cache if no one else gets around to it. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Zoran Vasiljevic wrote: On Saturday 15 March 2003 18:45, you wrote: Agree. I have skipped thru code and, apart from some typecasts, I see no problems. Hmmm ... I added a bunch of typecasts to avoid warnings at compile time, are you saying you had to add more or that you've taken some out? Most were to cast int to size_t - the code uses size information as a signed integer in some places (-1 as a flag) so simply changing the offending vars to size_t caused new warnings to pop up. The warnings I was getting rid of had nothing to do with the functionality I added, I just dislike our having code that generates warnings and took the opportunity to clean it up while I was working on it. I will import this in SF on Monday, if it is ok for you. Sure. I might do this while I port other modules. It should be relatively easy to do with srvPtr = NULL. Might turn out to be a trivial task. I would probably take the approach of adding a new command to ns_cache, using servPtr == NULL as a flag seems a bit of a kludge. Most of the code works on a cache pointer with no other context information, implementing a true global cache will just involve adding a new proc to use a static tcl hashtable to map the name to a cache pointer. You initializing that hashtable and an associated static lock the first time the module is loaded, and only the first time ... -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] ns_cache and virtual hosting ...
Tom Jackson wrote: Don, I would agree that we don't need both options at the moment, the main focus should be on making modules work with AOLserver 4.0, not enhancing them. If someone needs the global cache, they can just run the current version no? Can I get a copy of your code, plus any suggested config file settings/changes? If you need it before Monday (when Zoran will import it into SourceForge) let me know and I'll send it to you. No config file changes are required, it's totally transparent. In essence I tested this by pasting two existing AOLserver config scripts for two OpenACS test sites into one config script, ran AOLserver with the result and both sites came up with no problem. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] Tcl bytecode caching for Tcl pages
Bas Scheffers wrote: (Tcl only compiles code likely to be reused, which is procs, I expect the bytecode cache to do the same) The bytecode cache caches the top-level code for the page itself, that was the point. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] init.tcl
Elizabeth Thomas wrote: You could even look in home first and the bin directory containing nsd if it doesn't find one in home - on the off chance existing users have either customized it or have deleted the one in install-dir/bin. If you did this it wouldn't break any existing setups. This seems like a reasonable and desirable enhancement. Recommend submitting a bug/feature request in SourceForge (or even a patch :) ) It turns out that there are lots of places that expect stuff to be relative to the directory you were in when you run nsd, so a simple change like mentioned above isn't really useful. At some point the community should make some decisisons about how closely an AOLserver release should track expectations in the Linux/Unix world in regard to file locations. It's certainly easy enough to just install in my /home/aolserver directory (which I've always done in the past, it's just been so long that I guess I forgot why!) -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
[AOLSERVER] Tcl bytecode caching for Tcl pages
The custom AOLserver distributed first by Ars Digita then by the OpenACS project (AOLserver3.3+ad13 being the latest) included code to cache bytecode produced when Tcl pages are compiled. This hasn't made it into AOLserver 4.0, though ns_cache, upon which it depends, has. Was this intentional or an oversight? The code's been used successfully in many sites so seems stable. It's only enabled if you load ns_cache into your server, the code's identical to the existing file.tcl if you've not done this. I realize it's awfully late in the cycle to raise an issue like this, but we at the OpenACS project have been overjoyed at the prospect of telling people to use a stock AOLserver rather than our custom version. And we can actually do that regardless, since caching of bytecode's just a performance booster. Procs in one's Tcl library already have their bytecode cached by the Tcl compiler. So we (the OpenACS folk) could tell folks they can run with stock AOLserver 4.0 while making the caching version of file.tcl available for those who want it, then lobby for its inclusion in AOLserver 4.1. That would be the conservative approach ... Thoughts? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] Tcl bytecode caching for Tcl pages
Rob Mayoff wrote: +-- On Feb 23, Don Baccus said: The code's been used successfully in many sites so seems stable. But has it been proven to be effective? I haven't seen any numbers. I helped implement it, but I don't recall that we (ArsDigita) ever did a serious analysis of whether it improved performance. I've been thinking about doing some instrumenting but haven't had time. It is probably far more important that bytecode for procs be cached. On the other hand ... it's easy enough to turn off, though it would be nice if it could be enabled/disabled via a config param rather than automatically turning itself on when it sees ns_cache. I would think the benefit would be higher than previously given the speed improvements in strings and list processing in Tcl 8.4.1. In other words, if we assume compile speed's about the same and that average execution speed has increased considerably then the benefit of avoiding the compile step has increased over previous versions of Tcl. As I said in my first note, I'm perfectly comfortable with it not being in 4.0, with the notion that it might come back in 4.1 (or whatever comes next.) In that timespan we might find someone in the OpenACS project who'll undertake some analysis of its performance. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] init.tcl
Elizabeth Thomas wrote: Don, I think we would like to avoid having the install directory 'baked in' to the nsd in any way (it enables builds to occur on different machines/locations and the install directory be moved around as needed without requiring rebuilds). But but ... [ns_info nsd] exists and is used to find where nsd was called from. The assumption that it's being run from a coherent AOLserver install is already being made by the sample config script to locate modules like nssock.so. This doesn't bake in knowledge of the install directory in any way as it is discovered dynamically. Now ... it is possible that init.tcl is sourced before the directory nsd lives in has been located, but other than that I don't see a problem (and I doubt this is true.) You could even look in home first and the bin directory containing nsd if it doesn't find one in home - on the off chance existing users have either customized it or have deleted the one in install-dir/bin. If you did this it wouldn't break any existing setups. In the Unix world it's generally assumed that once you've installed something you don't need to keep any of the pieces around locally - not if the app is well-behaved, anyway. That it's safe to do a make distclean after a make install. We already have a world convinced that Apache is the One True Webserver. Little kinks like this are the kind of thing that might alienate someone casually investigating AOLserver. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org I. To remove yourself from this list: Send a message to [EMAIL PROTECTED] with the following text in the BODY of your message: signoff aolserver II. For a complete list of listserv options please visit: http://listserv.aol.com/ III. For more AOLserver information please visit: http://www.aolserver.com/
Re: [AOLSERVER] 4.0 build problems (nsoracle, etc.)
Andrew Piskorski wrote: On Sat, Feb 15, 2003 at 05:04:54AM -0500, Jeff Davis wrote: Andrew, I have built nsoracle on 4.0 several times without a problem. The one change I had to make to get ora8.c compile on 4.0 is: #include ns.h +#include nsdb.h #if !defined(NS_AOLSERVER_3_PLUS) -#include nsdb.h Ah, that did the trick. Thanks Jeff! Will the source be fixed for the final release? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org
