Re: [AOLSERVER] AOLserver facelift.
On Monday 07 February 2005 23:25, Dossy Shiobara wrote: Seems fair. I assume you will be putting responses bypassing this public list in some place where everybody can see them, right? Unfortunately, no. I thought about this and decided that I want to respect people's desire to remain anonymous in order to encourage their continued contribution. I hope this makes sense to everyone. People who wish their position to be public should do so by posting it in a public place (a website they control, mailing it to this mailing list, etc. -- but please, email me a copy or a link directly so I know about it). Well, I can't imagine why *anybody* would want to post his/her's wish-list secretly... But I can follow your reasoning. If you don't ask for it, you will likely not get it. Period. This is my wish-list. Do whatever you consider appropriate. It is *far* from complete, but I guess I have to start with something. (I have no reason of hiding it, I'm not secret service): - Refactor core to make http-protocol second-class citizen which would live peacefully with other protocols i.e. make http yet-another pluggable protocol - Add hooks to plugin alternate filesystems (Tcl VFS) so you can serve stuff out of zipfiles, for example - Examine what it takes to make a starkit out of the AS so that core plus selection of modules can be delivered as a single executable - Make the entire beast as Tcl module so you can plug it in the Tcl shell via package require aolserver. Note: not just the libnsd, the entire thing, rather. - Add better nsv's with more datatypes and shared Tcl object store plus more advanced thread handling (see Tcl threading extension) - Add process/machine-wide shared variables for simpler communication between server instances on one or several machines (this might be more of a module than core-stuff, ok). - Add Apple's Rendesvous (zero-config networking) so people can dynamically locate services provided by the AS platform - Make the server configuration dynamic instead of relying on the arcane ns_section/ns_param type of things. Ideally, one should be able to have a config repository in-memory with ability to set/change server parameters on-the-fly instead of on-the-startup only, if/where feasible. - Improve Tcl integration so sourcing of code in one becomes automagically available in other threads w/o much fuss (i.e. much better ns_eval pendant). Perhaps my ttrace module may be rewritten in C for better speed although I'm using the Tcl-pendant for about a year w/o visible speed penalty and memory footprint to about 1/3 of the initial. - Refactor ifdef'ed windows support into generic/platform-specific stuff for easier maintenance - Make windows a first-class-citizen platform - Add nsd watchdog-process respawning nsd if it dies. This can be extended to allow simple Tcl scripts which ping the server on the app-level and do some assert-like things to assure server is still behaving as expected - Convert docs in Tcl doctools format so you get instant HTML and nroff output and deliver that with the distro ... with more to follow. Zoran -- 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 facelift.
On Mon, Feb 07, 2005 at 04:25:46PM -0500, Dossy Shiobara wrote: Let's admit it, AS will never get so popular as apache or IIS and all efforts for making it popular without something that will differentiate it from apache is waste of time. Maybe I'm deluded, but I'm not ready to admit this yet. Just as we learned about the web browser war ... the web server war is far from over. This raises another thought. Dossy wants AOLserver to be much more popular than it is. Ok, what is most likely to cause that? Simple: One or more killer apps that happen to use AOLserver. Think about it this way, what percentage of AOLserver's popularity is entirely due to ACS/OpenACS? A big chunk, I bet. And OpenACS never became hugely popular, but it what if it had? AOLserver popularlity would have rode with it. And OpenACS is an example of just ONE potential AOLserver-using killer app. How many COULD there be? LOTS! Here's the ironic bit: Where could these new killer apps come from? Quite possibly, from projects like those using Stepen D.'s or Vlad's patches for multi-protocol support (using Asterisk, etc.) - which the AOLserver maintainer has been blocking. Or from some other entirely different enhancement to AOLserver, which will never be contributed because AOLserver has a pretty strong record of rejecting (or worse, ignoring) any such contributions. Oops, no more killer app! Just this week, a bunch of OpenACS folks were discussing (yet again) how to sell OpenACS into Apache shops. Technically, the two major proposals boiled down to: 1. Add FastCGI support to AOLserver. (Then AOLserver can be used as just another application server running behind Apache, just like the Java application servers, etc. that lots of Apache shops already run.) 2. Work on portable.nsd a lot more. (Use it with Apache, no AOLserver involved at all.) Here's the kicker: The guy who'd probably do most of the work, John Sequeira, seems to think that option 1. is a better idea technically, but is leaning towards 2. instead, because after following the AOLserver multi-protocol discussions, he doubts that any FastCGI work would ever be accepted by the AOLserver maintainers, no matter what! http://openacs.org/forums/message-view?message%5fid=263944 That looks symptomatic of a problem in how the AOLserver codebase is managed to me. Dossy, doesn't it look that way to you too? -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- 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 facelift.
Hi Dossy, I think the reason behind both issues is because the proposed contributions weren't that great. I'm sure this statement tweaks a lot of people, but I think it's the truth. I'm not the expert to verify that on the C level, but the situation was: There was a solution done by aD from Rob Mayoff and at least one version that patched the aD Part into the main 3.x line. The aD version was unmaintained with the fall of the company. And if your own company relies on AOLserver you would always like to see things incorporated into the main line rather in patches you don't know how many people use them (missing a lot of collaborative testing effort) and if they would work with the next server release. I guess the encoding/charset thing was one of the main stoppers for a lot of people to join the AOLserver community. So at that time it was not easy to understand why existing _and_ working code was not incorporated. Optimizations and code refactorings are always possible later on. JMHO. The upside is that in 4.1.x, expect to see a better way of handling the whole encoding/charset mess, along with better support for non-HTTP protocols in the core. Done right. (Yes, it's another major contribution from Jim Davidson.) Thats great. The current discussion, your RoadMaps, Feature Lists etc. reveal a lot of information. It would be great to have developments like these from the Core developers being summarized early on the Wiki! No matter if the changes are led by a Core Team or a Steering Committee, the important step would be decisions at all. For better or worse, I think I've been good about making decisions and following through as best I can. Of course! I like the activities that are going on! With decisions at all I specifically meant the result of all of what is being talked about in the moment. Everything is a process (tm). Bernd. -- 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 facelift.
On Tue, 8 Feb 2005 09:06:21 +0100, Zoran Vasiljevic [EMAIL PROTECTED] wrote: This is my wish-list. Do whatever you consider appropriate. It is *far* from complete, but I guess I have to start with something. (I have no reason of hiding it, I'm not secret service): Interesting list. Here's what I've been up to and what I'm planning: I've incorporated all the bug fixes and feature request I listed on sourceforge, plus the following additional items: Added a simple cookie API in C and Tcl. Ns_ParseObjv: A routine to ease writing Tcl procs in C by parsing switches, converting data types, writing error/usage messages etc. Created a Tcl callback infrastructure. This makes it easy to create Tcl versions of the many C hooks. Converted some existing code (tclresp.c, tclsched.c etc) to use this. Modified interp allocation to enter interps recursively. This prevents multiple interps per thread being allocated needlesly for the case when you call some command in Tcl which is a hook function, and the hook itself is implemented is Tcl. Virtualised page root handling. You can now register a function (C or Tcl) which returns the page root for the current server. This is *not* the same as url2file as the latter depends on the URL (but see my patches on sf where I've extended this). Create a simple nsmassvhost module which alters the page-root depending on the HTTP Host header. No config file entry needs to be made ahead of time, making it efficient to handle many virtual hosts. Incomplete: At the moment I'm attempting a re-write of Ns_Cache, i'm about 70% done. A much simpler interface is presented: Ns_CacheEval(), inspired by the Tcl module. No explicit locking is required. The Tcl API has been incorporated. The code is much smaller. I've written a new database driver manager, nsdbi. It's functional and aprox. 80% complete, although there are a lot of extra features that I'd like to add. Has native support for bind variables, doesn't use ns_set, gathers statistics, presents a nice Tcl API etc. TODO: Re-introduce the old Ns_ModLog or something similar. *everyone* re-writes this in Tcl. Authentication and authorization API. Important for multi-protocol work. More introspection, for example registered procs/filters (Rob Seeger mentioned this) Config parsing work: better handling of defaults, a command line switch to dump current state, etc. Tom mentioned this. Export more functionality to libnsd. I'm thinking that dummying up a conn request environment will allow easier testing. Plus a whole lot more. There's really a lot of great things that could be done. -- 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 facelift.
- Add hooks to plugin alternate filesystems (Tcl VFS) so you can serve stuff out of zipfiles, for example This in on my wish list as well. It would make plug-in storage for tDAV much easier. Right now tDAV cannot take advantage of fastpath since it makes C calls to the filesystem (for obvious performance reasons, i think). - Improve Tcl integration so sourcing of code in one becomes automagically available in other threads w/o much fuss (i.e. much better ns_eval pendant). Perhaps my ttrace module may be rewritten in C for better speed although I'm using the Tcl-pendant for about a year w/o visible speed penalty and memory footprint to about 1/3 of the initial. -- Dave Bauer [EMAIL PROTECTED] http://www.thedesignexperience.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 facelift.
This is my wish-list. Do whatever you consider appropriate. It is *far* from complete, but I guess I have to start with something. (I have no reason of hiding it, I'm not secret service): * A debug/development mode that reveals all running filters, triggered filters, better insight in memory consumption(s), encoding/charset stuff * Filters/Procedures: Have them as a list, delete them, reorder them * Don't having to restart the server only to re-read some config values. Maybe only as an option: For security reasons the current way is ok. * Having a 'real' config file with _all_ default values. Maybe the current grep-thru-code way could somehow be simplified. * Altering pageroot depending on HTTP host header plus dis-allowing any adp/tcl funcionality for these pageroots on a file level (no interpretation) as an option * Server-wide shared variables * Up-to-date patches for PHP (...) integration * Some kind of watchdog functionality ... Bernd. -- 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 facelift.
Hi - I read the entire thread mentioned below, and missed any mention of anyone saying the AS maintainers would not accept FastCGI. The other thing I guess I'm confused about, is that CGI is implemented as an AS module. Why can't someone write a FastCGI module, and whoever wants it can load it to get FCGI support? Does the core have to be modified to support FastCGI? And just as a my dog isn't in this fight observer, this discussion seems to be getting rather personal, which probably is not going to help it proceed productively. Jim Here's the kicker: The guy who'd probably do most of the work, John Sequeira, seems to think that option 1. is a better idea technically, but is leaning towards 2. instead, because after following the AOLserver multi-protocol discussions, he doubts that any FastCGI work would ever be accepted by the AOLserver maintainers, no matter what! http://openacs.org/forums/message-view?message%5fid=263944 That looks symptomatic of a problem in how the AOLserver codebase is managed to me. Dossy, doesn't it look that way to you too? -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- 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 facelift.
On Tue, Feb 08, 2005 at 11:04:24AM +0100, Bernd Eidenschink wrote: I think the reason behind both issues is because the proposed contributions weren't that great. I'm sure this statement tweaks a lot of people, but I think it's the truth. I'm not the expert to verify that on the C level, but the situation was: There was a solution done by aD from Rob Mayoff and at least one version that patched the aD Part into the main 3.x line. The aD version was unmaintained When he said, the proposed contributions weren't that great, I believe Dossy was referring to the multi-protocol support patches, not the Rob Mayoff's much older ad-* patches. (I will ignore for now any question of whether his evaluation was accurate or not.) I have NEVER heard anyone even suggest that Rob Mayoff's ad-13 patches were anything other than top quality work. I've also looked at some (not all) of that code myself in the past, and it seemed quite careful and conservative - targetted to be just what a project maintainer should want in a patch. AFAIK, Rob's series of ad-* patches were ignored simply because the then-current AOLserver maintainer was a jerk. (I was not following the AOLserver list then, but MANY people who were have made exactly that comment.) The fact that each of Rob's patches either fixed memory leaks or other bugs, or added critical-to-ACS functionality (encoding support, ns_cache Tcl API, *.tcl page bytecode cacheing), was apparently of no concern to that guy. Now that we have a better AOLserver maintainer, I'm SOMEWHAT confident that most of the old ad-* patches would have been accepted relatively smoothly. The AOLserver project finally reached the, all bugfix patches accepted smoothly point some time ago, and in fact has gone a bit beyond that. (E.g., Mayoff's old encoding work was finally forward ported, and I know Dossy accepted a small feature improvement patch from me; no doubt from others as well.) That's all good. The big open question in my mind is whether this progress will be extended to having more than two people, both of whom work for AOL, touch the AOLserver core code. Especially given the feature lists Zoran and Stephen D. just posted, (many of which they've already implemented!) I see LOTS of potential value in giving these guys free rein to contribute. Note that to date, the AOLserver project seems to have always had the not enough contributions accepted problem, NEVER the too many incompetent cooks stirring the soup problem. And so far all the cooks look pretty darn competent to me, so the main question is whether the door to the kitchen will be unlocked or not. I say unlock the door, and then all you chefs figure out how to coordinate your cuisines. Fearing that you might not care for the taste of some of the new dishes is not a good reason for keeping the kitchen door locked. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- 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 facelift.
On Tue, Feb 08, 2005 at 06:16:58AM -0800, Jim Wilcoxson wrote: Hi - I read the entire thread mentioned below, and missed any mention of anyone saying the AS maintainers would not accept FastCGI. Read the end John's 2005-02-07 post to that thread again. http://openacs.org/forums/message-view?message%5fid=263944#265126 The other thing I guess I'm confused about, is that CGI is implemented as an AS module. Why can't someone write a FastCGI module, and This is a technical question, and once John investigates further maybe it will out that all the FastCGI work he wants to do is best done entirely in an AOLserver module, without any changes to the core. But he probably can't KNOW that for sure until AFTER he's in the middle of doing the work! And damn, but what if when he's 80% done, it turns out that all his work is useless unless he can get a few small changes made to the AOLserver core? The risk that those changes might well be REFUSED regardless of their actual merit, is a serious risk to anyone like John interested in doing such work. And that is my main point. The harder you make it for people to contribute, the fewer people will bother to even TRY to contribute. In any human group, whether a tribe of African hunter gatherers or an Open Source project, there is some optimal point for how many obstacles you force new candidate members of the tribe to overcome. Too easy, with standards too lax, and you get herds of losers who muck things up, do lousy work, and don't much care because they place little value on their membership and status in the tribe anyway. Too hard, and only the obsessively perseverant bother to even try to jump through all the hoops, and the project eventually dwindles and dies from lack of new blood. I suggest that reaching the upper echelon of chiefs or respected elders in the AOLserver project - by which I mean those who are allowed and encouraged to hack on the core code - is currently too hard, not too easy. Tone down the obstacles a bit, get a few more smart hackers committing freely to the CVS Head - and I think we will all reap the benefits. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- 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_encrypt error
On Tue, 2005-02-08 at 11:33 -0500, Brooks Robertson wrote: Hmm, I have a pub and priv key in the nsecrypt dir. The log also indicates that the module was successfully loaded at startup. Would bad keys cause an invalid command name error on ns_encrypt? Nope. Are you using AOLserver 3.5.x or 4.x? I never updated the source to run under 4.x so no idea what problems could be caused. Daniel -- | --- | Daniel P. Stasinski | http://www.saidsimple.com | [EMAIL PROTECTED] | http://www.disabilities-r-us.com | --- | http://www.scriptkitties.com | Jabber: [EMAIL PROTECTED] | http://oneweek.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_encrypt error
In a message dated 2/8/2005 11:47:46 AM Eastern Standard Time, [EMAIL PROTECTED] writes: Nope. Are you using AOLserver 3.5.x or 4.x? I never updated the sourceto run under 4.x so no idea what problems could be caused. I'm running 4.03 and using a binary from aolserver.com. Not sure where togo from here.Thanks for the information. -Brooks -- 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 facelift.
On Tuesday 08 February 2005 06:20, Bernd Eidenschink wrote: * Having a 'real' config file with _all_ default values. Maybe the current grep-thru-code way could somehow be simplified. Check my new, 'complete' config file: http://rmadilo.com/m2/ starting at jnm.tcl Config file is broken into different files, based on branching/repeated sections. In the example case, I have three virtual servers: jnm, configtest and cf2, with jnm being the name of the 'main' or default server, although there isn't supposed to be a default. There are three nssock modules loaded and the three servers are spread among these, I have nsdb support shown, and threadpools, nscgi and a tcl module. The main config file is jnm.tcl here's the structure: /web/m2/jnm.tcl -- main config /nsdb-jnm.tcl -- main nsdb for the jnm server /nsdb-jnm-pg.tcl -- postgres db pool config /nsdb-jnm-pool[1-3].tcl -- symlinks to nsdb-jnm-pg.tcl /servers/jnm/config/ -- config directory for jnm /servers/jnm/config/server.tcl -- main server config for jnm /servers/jnm/config/nslog.tcl -- access log module configuration /servers/jnm/config/nscgi.tcl -- module named nscgi config /servers/jnm/config/threadpool-fast.tcl -- threadpool named fast /servers/jnm/config/module-name.tcl -- for other modules The scripts included try to be smart about loading virtual servers. First the config files for the server are read. If there are simple syntax errors, these are caught and the virtual server is removed from the list of servers. Next successful servers are added to ns/servers and mapped to the nssocks. If an nssock ends up with no virtual servers mapped, or the default virtual server for that sock had an error, the nssock is not added, otherwise the whole jnm server would fail to startup. Successful nssocks are read into the configuation file. It is easy to extend the functionality of this setup. Module maintainers can simply add a single file, containing all the config parameters (if one is needed). You just add the module name to the server.tcl file for the virtual server. NOTE: there is currently a bug in the virtual server loading. The nssock section must contain a defaultserver parameter, or the nssock, and the whole server fail to start (This is by design, and is correct). However, only the defaultserver of the last registered nssock is used. That is, one virtual server serves as the default virtual server for every nssock, even if there were never any maps to that virtual server in the nssockX/servers section. NOTE2: users of virtual servers running 4.0.8 or 4.0.9 should upgrade to 4.0.10, due to a DOS bug. If you need info, email me directly. * Altering pageroot depending on HTTP host header Should require one new api call, oh, and why not allow threadpools to operate on this info as well? As a fast workaround, chechout ns_rewriteurl, you can map within the server pageroot. Although this sounds not that good, since the actual pageroot might look like: /pages/ /pages/vserver1/ /pages/vserver2/ etc. You can 'disable' the main, or non-matching host header by having a default mapping, i.e. you could never reach /pages/. plus dis-allowing any adp/tcl funcionality for these pageroots on a file level (no interpretation) as an option * Server-wide shared variables Maybe we can get AOL to release the PROXY support which has a 'specialized tclsh', probably requires all this and more. Although Rob Mayoff's threadpool module seems great, I believe the threads are clones of the server they run in, thus they could be fat. If virtual servers could communicate to each other (on a publish/subscribe basis), just about any smallish server could be used, but I suspect the PROXY module used by AOL has even more useful features??? * Up-to-date patches for PHP (...) integration * Some kind of watchdog functionality Actually only a built in module would work very well, and fast. Every solution I've seen is a true hack, which is why it needs to be in core. tom jackson -- 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 facelift.
On 2005.02.08, Tom Jackson [EMAIL PROTECTED] wrote: NOTE2: users of virtual servers running 4.0.8 or 4.0.9 should upgrade to 4.0.10, due to a DOS bug. If you need info, email me directly. Unless this is a different DoS issue than the one we discussed, the fix requiring defaultservers was added in 4.0.8. So, as long as you're on = 4.0.8, you should be okay. Actually, I think only 4.0.6 had the DoS bug? Our email discussion said you were able to crash 4.0.7 without the Host: header, but that was exactly what the 4.0.7 release was supposed to fix (the bug was introduced in 4.0.6). -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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 facelift.
On Tuesday 08 February 2005 02:24, Stephen Deasey wrote: sourceforge, plus the following additional items: Added a simple cookie API in C and Tcl. Check out a tcl version of cookie code. It reads the Cookie header and writes both Set-Cookie and Set-Cookie2 headers. I believe it parses correctly, char-by-char, avoiding regexp. It is efficient in that it only runs once per connection, so if you need multiple cookies, you don't hunt through all the headers for every one. http://rmadilo.com/m2/servers/jnm/modules/tcl/twt/packages/cookie/tcl/ The package writes correct cookies with the exception of the path and max-age attributes. After developing the code, I discovered a bug in the Mozilla codebase, which includes Netscape and Firefox, where the surrounding quotes were not removed from either path or max-age. This caused the cookie to not be returned when path was set (it never matched), and/or for the cookie to be set as a session cookie if max-age was sent (since 800, with the quotes, isn't an integer value). The bug may be fixed by now, but I have no idea how long it has been there. Mozilla doesn't recognize the Set-Cookie2 header, so quotes could be added here without effect. tom jackson -- 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 facelift.
On Tuesday 08 February 2005 18:32, Andrew Piskorski wrote: On Tue, Feb 08, 2005 at 09:12:06AM -0800, Tom Jackson wrote: * Some kind of watchdog functionality Actually only a built in module would work very well, and fast. Every solution I've seen is a true hack, which is why it needs to be in core. A while back, didn't Zoran offer a simple patch to add in-core watchdog functionality? I think he did, but I don't remember for sure. I think Tom was referring to PHP, not to the watchdog. But, speaking of watchdog, I do have the watchdog done for us. Apparently most people are happy with servertools (is this the thing?). We're not since this is not something you can wrap in a product. It complicates installation/distribution. The AS is part of our product and our target is simple operation and simple installation/update. The built-in brain-dead watchdog process sits on top of nsd and respawns it in case it exits with code !=0 or signals. Not the rocket science but proved immensely important for support. Zoran -- 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 facelift.
On Tuesday 08 February 2005 09:31, Dossy Shiobara wrote: On 2005.02.08, Tom Jackson [EMAIL PROTECTED] wrote: NOTE2: users of virtual servers running 4.0.8 or 4.0.9 should upgrade to 4.0.10, due to a DOS bug. If you need info, email me directly. Unless this is a different DoS issue than the one we discussed, the fix requiring defaultservers was added in 4.0.8. So, as long as you're on = 4.0.8, you should be okay. Actually, I think only 4.0.6 had the DoS bug? Our email discussion said you were able to crash 4.0.7 without the Host: header, but that was exactly what the 4.0.7 release was supposed to fix (the bug was introduced in 4.0.6). Yep, you're right. I was running 4.0.7. But it does have the DOS bug, or at least on my machine, right now. I don't think I have tried 8 or 9. tom jackson -- 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] the something that is not right with the AOLserver project ... was Re: [AOLSERVER] AOLserver facelift.
On Tue, 8 Feb 2005 01:39:28 -0500, Andrew Piskorski [EMAIL PROTECTED] wrote: Please, *OF COURSE* the 3 guys who want to add multi-protocol support to the AOLserver core are a minority of AOLserver users! *YOU* are a minority of AOLserver users too, Dossy. Right. There's a huge difference between majority rules and stewardship. Today's installed base may not care one whit about multiprotocol support, OCaml integration or better documentation in Japanese. Today's users aren't the target audience, so trying to identify demographics in the current userbase is a strawman. Placating the majority here is a path towards stagnation and death, not innovation and growth. For the sake of argument, ~95% of AOLServers users don't and won't modify the codebase (including docs). And those same users don't use more than ~50% of the features in AOLServer. The issue isn't whether or not to enlarge the scope of the project to include a feature, like multiprotocol support. The issue *should* be whether to include that feature based on its merits. If ~95% of users next year do not use multiprotocol support, who cares? If we were talking about, say, turning AOLServer into an X-Window manager, mail reader and web browser, then the proposed changes would be questionable, because they are not in scope with the mission/goals of the project. -- Adam -- 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] the something that is not right with the AOLserver project ... was Re: [AOLSERVER] AOLserver facelift.
BNA uses AOLserver to produce publishing artifacts on web pages. We publish subscription content on the web. We use the server to produce HTML over the HTTP protocol. Our subscribers log into the web site and read / print what they need to get their own jobs done. End of story. The 5 line code change supports a dirt simple means of doing what looks like virtual hosting to the subscriber so that the product name appears as the hostname in the HTTP header. In the content on the web publishing business BNA is a late adopter and not exceptional at all. All BNA needs is a fast, stable, easy to use web server. AOLserver is all of those things and more. We just don't need to use the more part of it. I perceive the conversation to be about project support for the none HTTP business, the more part, that AOLserver also supports. Dossy Shiobara [EMAIL PROTECTED] wrote: On 2005.02.07, Greg Wolff [EMAIL PROTECTED] wrote: We LOVE AOLserver from at least one point of view: we don't need to do anything to it to make it work. It just works. In all our years of using AOLserver we have made exactly ONE source change to the core C code. [...] So, this raises the following questions: Is BNA an exceptional case? Or, do most users of AOLserver share a similar experience? Are the folks who are asking for changes in the core in the majority or minority? I think the answers to these questions are important. -- Dossy Dossy Shiobara [EMAIL PROTECTED] Sent by: AOLserver Discussion AOLSERVER@LISTSERV.AOL.COM 02/07/2005 04:37 PM Please respond to AOLserver Discussion To: AOLSERVER@LISTSERV.AOL.COM cc: (bcc: Greg Wolff/BNA Inc) Subject:Re: [AOLSERVER] the something that is not right with the AOLserver project ... was Re: [AOLSERVER] AOLserver facelift. -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. -- 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 manpages as HTML (was Re: AOLserver facelift.)
On Tuesday 08 February 2005 17:54, Dossy Shiobara wrote: - Convert docs in Tcl doctools format so you get instant HTML and nroff output and deliver that with the distro I'm not convinced that the Tcl doctools format is the way to go Have you ever tried doctools? Why are you not convinced? I've switched from hacking the XML and nroff sources to doctools for the Tcl threading extension and I never regreted the decision. It is very similar to Perl POD, but written with Tcl and the syntax is trivial - very much like the wiki. BTW, all Tcl Lib modules use it and I don't think people are unhappy with it. Zoran -- 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_encrypt error
On 2005.02.08, Brooks Robertson [EMAIL PROTECTED] wrote: I'm running 4.03 and using a binary from aolserver.com. Not sure where to go from here. Thanks for the information. Everyone, Brooks NOT using the nsencrypt module that's in SourceForge and available from aolserver.com. He's using a totally different (and AOL-internal) nsencrypt module which has a different Tcl API from the open source nsencrypt module. For those who are curious: the AOL nsencrypt module uses the RSA BSAFE library instead of OpenSSL. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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] multi protocol question
We're interested in using this work, too. A lot of our deployments (especially those that are focused on getting live [no-refresh] updates via JavaScript) end up being slowed down by the requirement to adapt to Javascript cross-domain security; we'd like to be able to run as an appserver behind other web servers, if it was easy. -- Rick Cobb -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] Behalf Of John Sequeira Sent: Tuesday, February 08, 2005 10:51 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: [AOLSERVER] multi protocol question I have a question regarding the multi-protocol patches discussed on the list in August. Was a decision made on these? Is it likely that AOLServer core would include this support anytime soon? I'm investigating whether it would be an option to add FastCGI support to AOLServer. I and a few others would like for Openacs to add other webservers to it's list of supported platforms while stealthily running AOLServer as an app server tier. This would get around a lot of the checkbox-based resistance encountered in the early sales process, and (we think) would allow organizations to consider AOLServer even if their infrastructure is locked into a particular web server. John Sequeira http://www.oreillynet.com/pub/au/1780 -- 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. -- 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] multi protocol question
On 2005.02.08, John Sequeira [EMAIL PROTECTED] wrote: I have a question regarding the multi-protocol patches discussed on the list in August. Was a decision made on these? Is it likely that AOLServer core would include this support anytime soon? It depends on how you define soon but my answer is yes, definitely. I'm hoping it's something we can get into 4.1.0. It can already be hacked into the 4.0.x tree, but hacked is the reason I'm not enthusiastic about doing it ... I'm investigating whether it would be an option to add FastCGI support to AOLServer. I and a few others would like for Openacs to add other webservers to it's list of supported platforms while stealthily running AOLServer as an app server tier. This would get around a lot of the checkbox-based resistance encountered in the early sales process, and (we think) would allow organizations to consider AOLServer even if their infrastructure is locked into a particular web server. To clarify, you want AOLserver to act as a FastCGI client? Can you explain the benefit of this approach, rather than having the front-end webserver simply proxy HTTP requests to AOLserver? This is where the Apache team is going with Tomcat with their mod_ajp connector for mod_proxy. Granted, the inter-server protocol will be AJP and not HTTP, but is that a material difference? To make AOLserver act as a FastCGI client, I'm thinking we should/could be able to do this without any changes to the AOLserver core. I would suggest we reserve the nsfastcgi module name for the module which allows AOLserver to run FastCGI apps under it. (And, you can already kinda do this today using the cgi-fcgi program to run FastCGI apps as normal CGI under AOLserver.) So, I suggest the name nsfastcgisock (akin to nssock which probably should be named nstcpsock for clarity). If the FastCGI Dev. Kit is thread-safe, we can just use FCGI_Accept() and take the data it hands back and craft a Ns_Conn request and do normal request processing and then send back the response however FastCGI wants it. /OR/, if we don't get adequate performance this way, we implement another DriverThread that speaks the FastCGI protocol and does its own socket handling. Obviously, the more refactoring that happens to the AOLserver core to decouple the network I/O from the ADP/HTTP request processing, the easier this will be to implement. However, I don't immediately see reasons why an nsfastcgisock (nsfcgisock?) can't be implemented today, with minimal changes to the core. And, if those changes to the core can be implemented by properly refactoring and decoupling the code, I'm all for it. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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 manpages as HTML
On 2005.02.08, Zoran Vasiljevic [EMAIL PROTECTED] wrote: On Tuesday 08 February 2005 17:54, Dossy Shiobara wrote: - Convert docs in Tcl doctools format so you get instant HTML and nroff output and deliver that with the distro I'm not convinced that the Tcl doctools format is the way to go Have you ever tried doctools? Why are you not convinced? While I would have no problems authoring in Tcl doctools, I expect not going with a more popular format will cause even fewer people to contribute documentation, if that's even possible. It's the reason why I've been tempted to try and reflow all the existing AOLserver documentation in DocBook XML -- not because I particularly care for DocBook or XML in general, but there's bound to be more people who know DocBook XML or at least more people who want to learn it. FYI, it's important to qualify it with Tcl doctools since there have been other implementations of documentation tools and formats called doctools in the past ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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] multi protocol question
On 2005.02.08, Rick Cobb [EMAIL PROTECTED] wrote: We're interested in using this work, too. A lot of our deployments (especially those that are focused on getting live [no-refresh] updates via JavaScript) end up being slowed down by the requirement to adapt to Javascript cross-domain security; we'd like to be able to run as an appserver behind other web servers, if it was easy. If other webservers we mean Apache, it should already be possible to use Apache's mod_proxy to turn Apache into a reverse proxy in front of AOLserver. Using mod_rewrite, you could do this selectively for only a subset of URLs to be passed through to AOLserver. I'm not sure what additional support we could incorporate into the core to make this work better. And, whatever that enhancement would be wouldn't really benefit anyone unless a complimentary change was made to Apache to take advantage of it ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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 facelift.
On Friday 04 February 2005 16:34, Tom Jackson wrote: C. Working examples of database integration, expecially ODBC and if possible MySQL. Other examples are mentioned as foreign: OACS, for instance. Note that ACS, and OACS are responsible for a large percentage of users, and these projects contributed the oracle driver and the postgres driver. AOL itself has done nothing to advance database integration, and the base nsdb module remains incomplete. If these drivers didn't exist, my interest in this project would be zero (0). Being that I'm one of the ones responsible, let me make it very clear that the current nspostgres driver is a derivative work from the ACS/pg (OpenACS) postgres driver, which is IN TURN a derivative of the original Postgres95 example driver written by Jim Davidson for AOLserver 2.x long long ago. I have been involved in that driver since AOLserver 2.2.1 and PostgreSQL 6.2.1 and tested the beta driver for AS2.2.1 for AOL long long ago (still have the e-mails, too). HOWEVER, the AS 2.x docs were and are much better than anything since. Basically everything you mention, Tom, was addressed fully in the AS2.x docs. I still have the AS2.3.3 doc set somewhere in PDF form. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu -- Lamar Owen CE WGCR AM 720 and WWW.WGCR.NET Director of Information Technology Pisgah Astronomical Research Institute 1 Peter 4:11 -- 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] multi protocol question
Dossy Shiobara dossy at PANOPTIC.COM writes: To clarify, you want AOLserver to act as a FastCGI client? Can you explain the benefit of this approach, rather than having the front-end webserver simply proxy HTTP requests to AOLserver? This is where the Apache team is going with Tomcat with their mod_ajp connector for mod_proxy. Granted, the inter-server protocol will be AJP and not HTTP, but is that a material difference? Thanks for such a comprehensive response :-) I believe for most of the world's departmental web servers which run IIS, mod_proxy is not really a good option. Although it runs well on Windows and could sit in front of IIS/AOLServer, it breaks important things like integrated security, and you end up with a few more moving parts than you really want to have. So, I suggest the name nsfastcgisock (akin to nssock which probably should be named nstcpsock for clarity). If the FastCGI Dev. Kit is thread-safe, we can just use FCGI_Accept() and take the data it hands back and craft a Ns_Conn request and do normal request processing and then send back the response however FastCGI wants it. /OR/, if we don't get adequate performance this way, we implement another DriverThread that speaks the FastCGI protocol and does its own socket handling. I didn't realize that a standard module might be able to handle this. So this doesn't necessarily require a core hack unless it has special thread or performance requirements? And even if it does, the multi-protocol patches that may make it into 4.1.0 would address this type of extensibility? I'm not sure about the fastcgi library's thread safety... that will be easy to find out. John Sequeira http://www.oreillynet.com/pub/au/1780 -- 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 facelift.
After lurking on the list for quite some time I have to say that I strongly second many of Tom's comments. PLEASE, don't take any of this personally none of it is aimed at individuals, and none is intended as anything other than constructive criticism. My thoughts mixed in below: -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: 05 February 2005 06:43 On 2005.02.04, Tom Jackson [EMAIL PROTECTED] wrote: 1. Ditch non-AOLserver technology. If it doesn't run under AOLserver, replace it with something that does. I too found it odd that the AOLserver sites themselves didn't use their own technology If someone is offering to donate freely, commercial-grade hosting on AOLserver, please contact me. Surely AOL could provide this as a way of thanking the efforts of the community developers? 2. Expose real world examples, and code examples. I agree. I also don't think the burden of responsibility lies solely on AOL to provide this. AOLserver is out there. The source is open and freely available. Folks outside of AOL are developing applications for AOLserver. They're free to publish their code as open source as well (i.e., OpenACS, .LRN, etc.) to serve as examples for everyone. There's a very serious dearth of easily usable AOLserver code out there. I suspect that many people who start to use AOLserver end up having to build for themselves the same very basic building blocks. So these basic blocks get built over and over again, making every implementation different and significantly raising the bar in terms of what is required to 'just get started' I'm an experienced Tcl programmer and had no difficulty in building a working demo 'page' (.adp or .tcl) once I'd got a working server. However it then took a whole bunch of time to implement sessions and a database driven security model, time which many people before me must have spent over and over again. Can't AOL and the AOLserver community spare some of its experience and help out by providing a recommended/reference version of some of these that would get most people started at least. 3. Provide configuration examples. What's missing from the sample-config.tcl? Provide a list, and we can discuss whether there's value in adding it in. I just spent a few days going through all the core code to pull out every config parameter. Great! Publish your findings on the web so others can benefit from your hard work. I did precisely this some time ago and published the results on this list. Guess what - sample-config.tcl came back more or less unchanged. In order to allow AOLserver to be more self-documenting, I suggest a slight change to the way AOLserver starts up. At the moment, modules look through the config ns_sets to find values. If they don't find a value, they use a default. The default is buried in C code and is impossible to find after the server starts up. The small change would be to have the procedure which checks for the value (and doesn't find one), to _add_ the default to the config ns_set. This would allow admins to always find what defaults are set (and what config parameters are available), after the server is running. This is an interesting idea. We can explore it for future AOLserver releases. It is a neat idea - I'd personally take it further and put all the defaults are in the config file and suggest that the server errors without them rather than having them hardcoded hidden away in the C code. 4. Ditch the AOL moniker. EVERY person I tell about what software I use is CONFUSED by this. Please describe their confusion. What are they confused by? What does the confusion result in? I personally got the impression that with AOLserver I'd get something off the shelf that with a certain amount of tweaking I'd be able to build sites not unlike the AOL site, and as my sites grew I'd be easily able to scale up. It turns out that off the shelf you get a vanilla webserver. Yes it may actually be very advanced,fast,scalable etc. but only *if you know how* and that knowledge is not easily available outside of AOL While the world has declared Apache and IIS the de-facto standards for web servers, Crazy isn't it! It is my belief that these servers have become de-facto standards, not because they excel at what they do but because they are easy to use. If they were actually any good they'd be very dangerous! :-) The number of people I speak to who think Apache is the fastest, most scalable, best webserver out there, for no apparent reason other than lots of people use it makes my mind boggle. The look of sheer bewilderment on their faces when you show the difference in performance between a multi-process and a multithreaded webserver is a sight to be seen. I actually think that people severely underestimate the incredible value of the AOL brand equity. I'm hoping in 2005, I can find more ways of capitalizing on it. To me that would
Re: [AOLSERVER] AOLserver facelift.
On 2005.02.08, Tim Moss [EMAIL PROTECTED] wrote: If someone is offering to donate freely, commercial-grade hosting on AOLserver, please contact me. Surely AOL could provide this as a way of thanking the efforts of the community developers? The downside of this is that no one from outside of AOL could ever get access to make changes to the site, because of the way security is set up. Right now, anyone inside or outside of AOL can make changes to the aolserver.com site if they're a project member of the AOLserver SourceForge project because aolserver.com is also hosted at SourceForge. Great! Publish your findings on the web so others can benefit from your hard work. I did precisely this some time ago and published the results on this list. Guess what - sample-config.tcl came back more or less unchanged. What were your expectations? What needs to happen for your expectations to be met? Am I the only one who can do the necessary? What can I do to delegate the necessary authority to enable to you to self-serve your expectations? I think that's going to be my motto for 2005: What can I do to enable you to self-serve your expectations? It is a neat idea - I'd personally take it further and put all the defaults are in the config file and suggest that the server errors without them rather than having them hardcoded hidden away in the C code. (Sane) defaults are nice. It allows for sites to go through upgrades without having to do a lot of configuration file management. But then, in past lives, I was the sole sysadmin of over 100+ hosts, so I really appreciate designs that minimize effort on the admin. to maintain and operate ... However, I do agree that there needs to be an updated Admin. Guide that documents all the various knobs and switches that can be manipulated. Who's up for that task? :-) 7. Release more code. For a specific example of what I am talking about, consider the NV: network variable. For _years_ I have been inquiring about NVs, since Jim Davidson mentioned that they are used by AOL. An NV is simply shared data, available to multiple physical servers, a networked nsv, I suppose, but maybe more. This would serve the same essential purpose of a javabean I think. Hear hear! This is the kind of generic extremely useful code that AOL must have lying about that is unlikely in itself to be a trade secret, but would be of huge assistance to the community developers. Actually, it turns out that the AOLserver implementation of NV could very well have been patentable when it was first designed and implemented. I don't know true this is, but it's something to consider carefully. It's also a concern that many open source projects seem to be completely oblivious to: accepting contributions can be dangerous, if it implements functionality that somehow violates someone else's patent or otherwise protected intellectual property. As frivolous as the SCO vs. Everyone lawsuit may seem at the surface, it's a real threat and I imagine most open source projects don't have the money for the necessary legal counsel needed to defend against such threats. That's not a good argument to use. If one has a choice between some code that will handle X thousand requests/users/whatever and some that is known to handle X million requests/users/whatever, which would you prefere to use even if you don't need that capacity right now? Do you live in a 32-bedroom mansion all by yourself? Do you drive an 18-wheeler truck to commute to your corporate job? There's an inherent beauty in right-sized solutions. Start completely from scratch Or Start from stock OpenACS I personally wanted something in-between and there wasn't anything I suspect I'm not alone. Did you publish what you've developed from scratch? Put a OSI-approved license on it (preferably the AOLserver Public License) and lets declare it the in-between solution. That doesn't solve the real problem ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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 facelift.
Dossy quoted Tom: 6. Split the discussion between C level source code and applications. There's few enough AOLserver developers who deal at the C code level that having a separate mailing list In reply, On Tuesday 08 February 2005 14:01, Tim Moss wrote: I too don't think splitting the list would help at this stage - you might end up with an us and them elite vs. newbies split which never helps. Amazing when you take a single sentence, and forget the following two paragraphs labled A B. I was speaking of the website, not the mailing list. I'm not suggesting any changes to the mailing list (unless we could ditch the less than reliable software which runs it). Without discussion on the website about how to use AOLserver, via Tutorials, etc. Right now the website is 100% about AOLserver, the software. And several times in the last few days Dossy has directly said: go somewhere else for examples. If the website is going to remain about AOLserver (the massively scaleable engine behind Digital City), then lets here about all the software that makes it so, because AOLserver itself isn't. I've mentioned in an email earlier today that I have compiled a complete (or 99% complete) list of config parameters, for the modules I have had time to work on. The example also makes it easy for module maintainers to add a single file which documents all the parameters used. http://rmadilo.com/m2/config.tgz contains just the config files. If for no other reason than documentation purposes, all config parameters should appear in the config files, so you can get the values after startup. lib_broadcast.tcl Broadcast Service It's not AOL's NV implementation, but it's *an* implementation that's already available. Hmm very interesting and very cool - last time I looked there the NV stuff was by its own admission only partially functional. It uses HTTP GET! I'm impressed. I started a simple package called tclbean, which allows you to get/set nsv's on another AOLserver. It isn't implimented correctly, but I'm fixing it. I see two types of NVs: push/pull and subscribe/broadcast. The push/pull variety would never maintain state on the client and could push values as well as retrieve them. Subscribe/broadcast is more like what Jim Davidson described. NVs can be used to cache database queries, or any other data which is dynamic, but within a given timeframe appears static. tom jackson -- 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.
[AOLSERVER] AOLserver, NTLM, Apache+mod_proxy, and FastCGI (was Re: multi protocol question)
On 2005.02.08, John Sequeira [EMAIL PROTECTED] wrote: When you say integrated security are you talking about the NTLM auth scheme for HTTP? As long as mod_proxy properly handles HTTP Keep-Alive, and recent Apache mod_proxy does, NTLM auth should work just fine. We're talking about different things. In Unix, you can use Apache/mod_proxy + AOLServer to combine url spaces and use AOLServer much like an app server. Agreed Actually, we're talking about the exact same thing. In Windows, you can use an Apache reverse proxy to combine AOLServer and IIS URL spaces, but only IIS will be able to do the NTLM handshaking required to get a network ID. AOLServer would sit behind Apache and get the proxied Apache request without any single sign-on info at all. Are you sure about this? Do you have network sniffs showing what's actually happening between the browser and the server(s)? If Apache's mod_proxy is smart and its Keep-Alive is smart, then fronting IIS and AOLserver with Apache+mod_proxy should just work with respect to NTLM auth. As long as the server keeps the TCP connection alive to the client, the browser doesn't know what server is processing its request on the back-end, so it has to keep sending the Authorization: HTTP request header regardless. mod_proxy should be just passing this header along as-is to whatever back-end server is responsible for handling the request, regardless of whether it's IIS or AOLserver. It'd be kinda fun to implement an nsntlm module for AOLserver so you could use NTLM auth in AOLserver on Win32. NTLM auth is really nothing more than the server responding 401 Unauthorized w/ appropriate WWW-Authenticate headers, followed by 403 Access Denied w/ WWW-Authenticate headers, examining the Authorized header that comes back from the browser. However, the only browser that speaks NTLM is MSIE, right? Not sure how much value there would be in implementing this module and/or who would actually ever use it for anything real ... I'd be happy to work on an initial proof-of-concept implementation if you think there's a real application for it. YES! Please -- it would be insanely great to have a starting point. Lets be clear: you want to see a module for AOLserver that lets you run AOLserver as a FastCGI app. under a different webserver? Is this a just to see if it's possible or I would use this in my production environment as soon as I could kind of ask? I'm still not convinced that anyone would seriously run AOLserver as a FastCGI app. fronted with another webserver. Or, to rephrase: anyone who's willing to do so with the necessary performance impact that it will entail ought to look at a simpler solution like mod_proxy or some other reverse proxy software. Do you have a sense for how much slower this would be? Are we talking about a fractional performance hit or order of magnitude? I am guessing fractional. mod_proxy isn't remarkably slow, even when used with mod_rewrite -- I used to use caching mod_proxy+mod_rewrite before I switched to Squid for my personal uses. It wasn't much slower than Apache is in general, at least. (I am not convinced sane people would choose e.g. Cold Fusion, but that didn't seem to effect its popularity) Exactly. For small enough sites (e.g., the kind of ones who'd try to implement some cock-eyed architecture like what we're discussing), is the traffic going to even approach the level where scalability is going to be a real issue? The app.'s poor design will likely to be the bottleneck before the thin proxy layer ... FastCGI has the benefit to being as old a technology as AOLServer (older?). It's very likely someone has done what you want to do, and has uncovered the hiccups. I'll ask. I remember the nightmares of making FastCGI work in a multi-threaded webserver (Netscape Enterprise Server) many years ago. I think FastCGI was meant to accelerate the multi-process app. area -- folks who had multi-threaded stuff already had a faster CGI-like app. development environment than FastCGI. :-) -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
[AOLSERVER] AOLserver Tutorials on the Wiki (was Re: AOLserver facelift.)
On 2005.02.08, Tom Jackson [EMAIL PROTECTED] wrote: Without discussion on the website about how to use AOLserver, via Tutorials, etc. [...] I urge anyone and everyone to contribute whatever tutorials they can write: http://aolserver.com/wiki/Tutorials There's a few things already there, but I totally agree -- there could be a lot more. There's nothing stopping you (plural) from adding a tutorial of your own! Perhaps someone could write up a How to set up SQL-Ledger under AOLserver tutorial? Would be a good example of how to configure nscgi for at least ONE apparently popular CGI-based app. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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, NTLM, Apache+mod_proxy, and FastCGI (was Re: multi protocol question)
Dossy Shiobara wrote: On 2005.02.08, John Sequeira [EMAIL PROTECTED] wrote: Are you sure about this? Do you have network sniffs showing what's actually happening between the browser and the server(s)? If Apache's mod_proxy is smart and its Keep-Alive is smart, then fronting IIS and AOLserver with Apache+mod_proxy should just work with respect to NTLM auth. As long as the server keeps the TCP connection You are correct. My point was only that AOLServer would get the header unmodified, and then not be able to do anything useful with it lacking something like nsntlm. If IIS sat in front (i.e. using FastCGI), IIS could do the ntlm negotiation and pass thru the decrypted remote_user credentials, so AOLServer could take advantage of single-sign-on without doing any work. Lets be clear: you want to see a module for AOLserver that lets you run AOLserver as a FastCGI app. under a different webserver? Is this a just to see if it's possible or I would use this in my production environment as soon as I could kind of ask? Yes, a module to allow AOLServer to run as an app under a different webserver is what I'm asking for. (FastCGI External Server is how the mod_fcgi refers to it) I expect that 'just to see if it's possible' would be enough to bootstrap this. As in, .LRN and/or OpenACS would likely have paying customers (or could secure a grant) to underwrite the migration to a production quality module. I really do expect that to be the case -- in implementing portable.nsd, I have corresponded with at least three organizations willing to pay for either Apache or IIS support at one time or another. Would the prototype be something you could do? John Sequeira http://www.oreillynet.com/pub/au/1780 -- 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, NTLM, Apache+mod_proxy, and FastCGI (was Re: multi protocol question)
On 2005.02.08, John Sequeira [EMAIL PROTECTED] wrote: You are correct. My point was only that AOLServer would get the header unmodified, and then not be able to do anything useful with it lacking something like nsntlm. If IIS sat in front (i.e. using FastCGI), IIS could do the ntlm negotiation and pass thru the decrypted remote_user credentials, so AOLServer could take advantage of single-sign-on without doing any work. Could or does? What /does/ the FastCGI ISAPI module for IIS do? Does it get the NTLM auth data and pass it along, decrypted, to the FastCGI app.? If it doesn't, then this whole reason to run AOLserver as FastCGI becomes moot. Yes, a module to allow AOLServer to run as an app under a different webserver is what I'm asking for. (FastCGI External Server is how the mod_fcgi refers to it) Okay. I expect that 'just to see if it's possible' would be enough to bootstrap this. As in, .LRN and/or OpenACS would likely have paying customers (or could secure a grant) to underwrite the migration to a production quality module. I really do expect that to be the case -- in implementing portable.nsd, I have corresponded with at least three organizations willing to pay for either Apache or IIS support at one time or another. To be clear, this isn't /replacing/ AOLserver with Apache or IIS, but simply allowing Apache or IIS to front an AOLserver. I can totally understand someone wanting to fund the necessary development to make OpenACS or .LRN work without AOLserver /at all/, but I don't see the motivation to pay to add yet another layer of complexity to the stack ... But as you said, if decision-making were founded in good sense and were about the value proposition, how does one explain such things like ColdFusion. :-) Would the prototype be something you could do? Sure, lets aim for the end of March. I know it's a long time between now and then, but there's really no point in me giving an earlier date if I couldn't hit it. Who knows, I might have something testable by next weekend ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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, NTLM, Apache+mod_proxy, and FastCGI (was Re: multi protocol question)
On 2005.02.08, John Sequeira [EMAIL PROTECTED] wrote: To be clear, this isn't /replacing/ AOLserver with Apache or IIS, but simply allowing Apache or IIS to front an AOLserver. I can totally understand someone wanting to fund the necessary development to make OpenACS or .LRN work without AOLserver /at all/, but I don't see the motivation to pay to add yet another layer of complexity to the stack ... There are some in the OpenACS/.LRN community who claim that we'd get greater acceptance if we ran under Apache even if that meant simply running AOLserver as an app fronted by Apache. I'm not a big believer, myself, but the claim has been made by some that they've lost busines that they could've won if this were true. If they or you or other interested parties choose to do the work, funded or on a volunteer basis, they'll then be able to test their hypothesis in the marketplace :) But as you said, if decision-making were founded in good sense and were about the value proposition, how does one explain such things like ColdFusion. :-) That's the spirit of the proposal as I understand it! -- 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 facelift.
-Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: 08 February 2005 23:21 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] AOLserver facelift. On 2005.02.08, Tim Moss [EMAIL PROTECTED] wrote: If someone is offering to donate freely, commercial-grade hosting on AOLserver, please contact me. Surely AOL could provide this as a way of thanking the efforts of the community developers? The downside of this is that no one from outside of AOL could ever get access to make changes to the site, because of the way security is set up. I see - I can imagin there'd be a lot of red tap involved getting anything like this sactioned by the security folks. What if the site were pulled out of CVS once sanity checked? Right now, anyone inside or outside of AOL can make changes to the aolserver.com site if they're a project member of the AOLserver SourceForge project because aolserver.com is also hosted at SourceForge. Yep point taken - 'tis a shame that the aolserver.com site isn't its own example site running on AOLserver itself. Is there anyone within soruceforge that could be contacted to help arrange such a setup? I did precisely this some time ago and published the results on this list. Guess what - sample-config.tcl came back more or less unchanged. What were your expectations? I sort of expected some sanity checking by some of the resident experts of the new config.tcl file I provided (it was around 4.03 I think) and included examples of setting up vservers which were confusing folks at the time). I then expected some discussion on the list if anyone cared and once some form of agreement was reached (either through debate or silence) sample-config.tcl to be updated with anything useful. The silence was the only thing that happened What needs to happen for your expectations to be met? Some of the above! Am I the only one who can do the necessary? Probably not - changes to something like sample-config.tcl need to be considered generally useful and helpful, so it probably needs discussion agreement. But maybe the way to stimulate that is to go ahead an make the changes and be prepared for a few flames afterwards What can I do to delegate the necessary authority to enable to you to self-serve your expectations? I think someone of some group of people need to take ideas/suggestions etc. and drive them forward so that they don't just end up as random patches on sourceforge than ultimately wither and die I think that's going to be my motto for 2005: What can I do to enable you to self-serve your expectations? Hehe - sounds like the way forward for an easier life for someone! (Sane) defaults are nice. It allows for sites to go through upgrades without having to do a lot of configuration file management. Well maybe a 2 tier config system should be the standard defaults.tcl that contains all the (sane) defaults and is recommended not be altered on a particular installation, with a second file e.g. site-defaults.tcl for an admin to override defaults at will. That way after upgrades etc. defaults.tcl gets updated from CVS, site-defaults.tcl stays largely the same, unless addiitonal new parameters need to be overridden. Might help keep change management low. Other thoughts on this area would be: - to allow retrieving config from a DB of some sort or another - shipping a web GUI for producing a config file from the defaults plus any changes made via the GUI - allowing changes to config post startup - nice ways of having some common config (for a farm of servers) and some host specific stuff But then, in past lives, I was the sole sysadmin of over 100+ hosts, so I really appreciate designs that minimize effort on the admin. to maintain and operate ... However, I do agree that there needs to be an updated Admin. Guide that documents all the various knobs and switches that can be manipulated. Who's up for that task? :-) What I did previously is here http://site-speed.com/aolserver/sample_nsd.tcl - its out of date though (about 4.04 I think) but has some commentary for most of the knobs and switches. 7. Release more code. For a specific example of what I am talking about, consider the NV: network variable. For _years_ I have been inquiring about NVs, since Jim Davidson mentioned that they are used by AOL. An NV is simply shared data, available to multiple physical servers, a networked nsv, I suppose, but maybe more. This would serve the same essential purpose of a javabean I think. Hear hear! This is the kind of generic extremely useful code that AOL must have lying about that is unlikely in itself to be a trade secret, but would be of huge assistance to the community developers. Actually, it turns out that the AOLserver implementation of NV could very well have been patentable when it was first designed and implemented. I don't know true this
Re: [AOLSERVER] AOLserver facelift.
-Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Tom Jackson Sent: 09 February 2005 00:55 To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] AOLserver facelift. Dossy quoted Tom: 6. Split the discussion between C level source code and applications. There's few enough AOLserver developers who deal at the C code level that having a separate mailing list In reply, On Tuesday 08 February 2005 14:01, Tim Moss wrote: I too don't think splitting the list would help at this stage - you might end up with an us and them elite vs. newbies split which never helps. Amazing when you take a single sentence, and forget the following two paragraphs labled A B. I was speaking of the website, not the mailing list. Sorry Tom - I misunderstood - I wrote my reply at about 2 in the morning - never a good idea so here we go again! :-) Having developed in C and Tcl for many years, and having come across AOLserver and having fallen in love with it relatively late in life, but finding aspects very frustrating I hoped my perspective on the discussion about how to make the AOLserver project more appealing would be of value. In short my view is the more standardised Tcl code there is available that provides basic blocks for building applications, in particular web applications, the more people will use AOLserver. I'm capable of writing C modules for AOLserver, but chances are they wont be very portable, unlikely to be thread safe and quite honestly probably wouldn't perform much better than a Tcl version - largely because my C is rusty so I've lost a lot of that kind of expertise. In my experience it would only be maintainable/usable by a relatively small audience. Were I to write a Tcl module chances are it would be finished faster, pretty portable, would be thread safe and would probably perform well. I believe it would be usable/maintainable by a wider audience, and modifying it is just a matter of changing a textfile and testing rather than getting into the complications of compiling/linking etc. - If better performance was required then a C version would be easily deduced from the Tcl code - the reverse would be less easy. I find it a shame that this discussion (which has drawn out more people and interesting ideas on the list than I knew existed) has degenerated in places to personal insults and pedantism over very fine details - so often the way amongst groups of tecchies though; perhaps its inevitable. I've mentioned in an email earlier today that I have compiled a complete (or 99% complete) list of config parameters, for the modules I have had time to work on. The example also makes it easy for module maintainers to add a single file which documents all the parameters used. http://rmadilo.com/m2/config.tgz contains just the config files. If for no other reason than documentation purposes, all config parameters should appear in the config files, so you can get the values after startup. If it is of any use to anyone (it worked around about 4.03 4.04 I think) here's my sample config file with all of the server config values in it and some of the common modules: http://www.site-speed.com/aolserver/sample_nsd.tcl -- 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.
[AOLSERVER] Better documentation of available config options (was Re: AOLserver facelift.)
On 2005.02.09, Tim Moss [EMAIL PROTECTED] wrote: If it is of any use to anyone (it worked around about 4.03 4.04 I think) here's my sample config file with all of the server config values in it and some of the common modules: http://www.site-speed.com/aolserver/sample_nsd.tcl One thing I forgot to mention is that I'm hoping to have at least all the core AOLserver modules and their config options documented. For example, see: nslog: http://cvs.sourceforge.net/viewcvs.py/*checkout*/aolserver/aolserver/nslog/nslog.html?rev=HEAD nscgi: http://cvs.sourceforge.net/viewcvs.py/*checkout*/aolserver/aolserver/nscgi/nscgi.html?rev=HEAD See the sections for Configuration Options and Sample Configuration. I think documenting it this way instead of having one large annotated config file might be a more useful and/or usable way of presenting all the various knobs and switches available to users. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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] Hosting, discussions, branching, modules
After reading throught the digest of the discussion on this list and remembering Dossy's statement about donating a server, I'm more than inclined to ask the OpenACS Core Team to allow the creation of an AOLserver community at openacs.org or host a service on one of our machines. For one, I think using a forum is more user friendly, especially if you only read the digest. Furthermore the file storage would allow us to exchange files and patches without putting them on CVS and/or rely on sourceforge. On a related note, what is the downside of having an AOLserver stable branch, where only the AOL approved developers have access to and a testing branch where everyone can add their patches to. Needless to mention that from time to time the stable branch needs to be merged with the testing one. As for importance of development, if Dossy is strikt about not letting others participate actively in the core development (read: give them CVS access without the need for one person to accept patches), then the main interest would be to rewrite the modules part of AOLserver to a degree where all the functionality that has been written and needs patches to work can work smoothly as a module. And while we are at it, we could write an Apache Modules wrapper ;-). -- 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.
[AOLSERVER] Asterisk and AOLserver
While reading the previous postings I stumbled upon multiple mentioning of multi protocol support and asterisk, therefore I assume people on this list are knowledgeable about this topic. Here is what we need: We run a CRM system on top of AOLserver. The CRM system contains the phone numbers of the clients. I want my PBX connected phone to make a connection to the client if I click on a link in the CRM System. Once the phone call is finished, the CRM system should be notified about this, so it can add a new entry in the call history. Same goes the other way round, if the client calls me, the CRM systems starts logging and once finished, an entry is added. Any clues, hints, offers, suggestions, RTFM advises on how to achieve this ? -- 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.
