Re: [AOLSERVER] aolserver focus
On 8/7/07, Dossy Shiobara [EMAIL PROTECTED] wrote: 1) JavaScript: the SpiderMonkey JS engine is thread-safe and I've been integrating it into AOLserver (see: nsjsapi). John Resig has started a small JS library that makes running some client-side JS on the server-side, which I'm hoping to take advantage of. My rationale here is that JS is probably the single web scripting language that is known by the most number of people; regardless of which web stack you use, you're also going to have to use JavaScript. Why not just build the entire web stack with JavaScript, on the client and server side? Wow - that's very exciting. I always thought Javascript on the server was a good idea, but after Netscape's server folded it never really got picked up by anyone else. Javascript is a fantastic language - excellent OO and functional support, familiar syntax, and there are a lot of developers (now) who understand it's intricacies well. Dossy I assume nsjsapi is in cvs? I'll go check it out. -- 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 focus
Dossy, or some other knowledgeable person, could you add something to the wiki about this, if only so that people know it's there, and can find out who to talk to/how to help if they're interested? This sounds extremely interesting to me although I don't quite yet understand what server-side JS would look like. Titi Ala'ilima Lead Architect MedTouch LLC 1100 Massachusetts Avenue Cambridge, MA 02138 617.621.8670 x309 -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Mark Aufflick Sent: Wednesday, August 08, 2007 8:27 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] aolserver focus On 8/7/07, Dossy Shiobara [EMAIL PROTECTED] wrote: 1) JavaScript: the SpiderMonkey JS engine is thread-safe and I've been integrating it into AOLserver (see: nsjsapi). John Resig has started a small JS library that makes running some client-side JS on the server-side, which I'm hoping to take advantage of. My rationale here is that JS is probably the single web scripting language that is known by the most number of people; regardless of which web stack you use, you're also going to have to use JavaScript. Why not just build the entire web stack with JavaScript, on the client and server side? Wow - that's very exciting. I always thought Javascript on the server was a good idea, but after Netscape's server folded it never really got picked up by anyone else. Javascript is a fantastic language - excellent OO and functional support, familiar syntax, and there are a lot of developers (now) who understand it's intricacies well. Dossy I assume nsjsapi is in cvs? I'll go check it out. -- 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 focus
Hi, After reading through all the responses to my aolserver focus post, it seems to me Thorpe's comments below are the most realistic and actionable, i.e., it's the documentation / getting started stuff that's insufficient. Otherwise, technically there are a few things that could be fixed to solve some pain points: -- Close the gap between AOLserver's init framework and Tcl's package framework so tcllib, ActiveState Tcl, etc. can be used easily (needs those things to be verified, compiled, and available thread-safe) -- Figure out some AOLserver-as-an-Apache extension thing -- perhaps a more convenient proxy (seems possible) or a direct Apache module (possible but perhaps too incompatible and goofy to be useful). -- Close some API's gaps, e.g., Url2File (aka mod_rewrite) only available in C and goofy to use. It seems if we got those things done we could then consider other cool ideas, e.g., new language support (js, php) which shares the adp output buffer so you could mix-match, better integration with memcached, etc. Is it time to bucket these ideas and vote on what, if anything, to do? -Jim On Aug 8, 2007, at 4:19 AM, Thorpe Mayes wrote: I predict that AOLServer will be gone within 10 years. Maybe 5 years. People will say: It was really good software. I do not know what happened. It does not have to turn out that way. This is the second time in a year or so that I have seen this discussion on this list. It always generates a lot of activity and emotion. I believe that this is an indication that AOLServer is in its death throes. My friends, it does not have to turn out that way. The problem with AOLServer is not technical. It is not related to the people who work hard and unselfishly to develop the software. It is not because it is lacking in features. Instead, the problem is that it is not accessible. Consider this: Junior Programmer, the IT guy at a non-profit, has been given the task of setting up a web site that is easy to update, has a calendar and event function, has a restricted area for board members to access meeting reports, and allows users to register to receive a newsletter delivered by email. Junior has installed the latest version of Linux on his server. The installation software guided him through the process and he bought a book that served as a reference. (You will be shocked to learn that most people who manage servers are not programming geniuses.). He installed qMail by downloading the software and following the guidance in the qMail book he bought and by going to the qMail web site where there are detailed instructions covering the installation of the software. He installed D. J. Bernstein's daemntools software by following the detailed instructions on the web site. Now, he wants to run a web server. He knows about Apache and has heard about AOLServer. So, he Googles Installing Apache and Installing AOLServer. Guess which server software Junior decides to use. It is not AOLServer. I think most people will agree that the popular and influential religions all have a written document that explains themselves to potential clients. The same is true for open source server software. Several years ago there was talk about an AOLServer book. It never materialized. If you want this software to have a chance of surviving, you need to write a document that explains the software to the unwashed masses. It does not have to be exhaustive. Keep the 80:20 rule in mind: most people will use only 20 percent of the software's features. Figure out what those are and address them thoroughly. Leave the rest to the developers and those with special needs. Here is a starting point: 1. Introduction Tell people what AOLServer does and how great it is. When they finish this chapter, they should be convinced that this is the way to go. 2. History AOLServer has a history. Tell people what it is. The history will establish its bone fides and help sell the software. 3. Installation This needs to be very detailed (remember Junior Programmer). Show how to install the software on the major variants of Linux, MS Windows, and Mac OS. Leave out the obscure operating systems. Cover every step. Do not assume that Junior knows anything. Tell Junior what folders to create and where to create them (Programming Geniuses will know that they can do whatever they want, but Junior is nervous and wants to have his hand held.) Cover troubleshooting issues. You cannot cover everything, but there are some common errors that should be discussed. Give instructions on how to test the software. 4. Review the essential features Do not just list them and assume that Junior will figure it out. Go into detail and give examples. Provide a complete list of configuration parameters and explain how to use them Cover ns_ functions. Talk about how to use them. Cover tcl
Re: [AOLSERVER] aolserver focus
Dossy Shiobara wrote: On 2007.08.09, Jim Davidson [EMAIL PROTECTED] wrote: After reading through all the responses to my aolserver focus post, it seems to me Thorpe's comments below are the most realistic and actionable, i.e., it's the documentation / getting started stuff that's insufficient. Indeed, Thorpe's message was on-the-spot. As he mentions, there was an effort a while ago where Matthew Burke and I wrote a draft TOC and circulated it to several publishers, but we never actually started real work on the manuscript. I wish I were disciplined enough to complete such a book ... -- Dossy I realize its the lame answer to every similar problem in every open source community, but why not get it started on the wiki? I'd start by cutting and pasting Thorpe's TOC onto a new wiki page, but I'm not clear on what community editing processes (if any) are in place on the wiki. -J -- 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 focus
On Thursday 09 August 2007 08:46, Jim Davidson wrote: Otherwise, technically there are a few things that could be fixed to solve some pain points: -- Close the gap between AOLserver's init framework and Tcl's package framework so tcllib, ActiveState Tcl, etc. can be used easily (needs those things to be verified, compiled, and available thread-safe) More integration with the Tcl community is important. Both communities have added to the other. What are the issues? What would be the result of closing the gap? -- Figure out some AOLserver-as-an-Apache extension thing -- perhaps a more convenient proxy (seems possible) or a direct Apache module (possible but perhaps too incompatible and goofy to be useful). I have never been able to put my finger on what the issue is here. AOLserver isn't Apache. Sendmail isn't Qmail either. Both compete over a single privileged port. That is the real issue. Some company only has one IP address and needs to make a choice. Then just run AOLserver on an internal IP and proxy through to it. That is the module. Call AOLserver an application server and Apache a firewall. Nobody is complaining that Oracle doesn't run inside AOLserver or Apache, what difference does it make if your application server is a separate process, maybe on a separate machine. Really it is a benefit, a security feature. -- Close some API's gaps, e.g., Url2File (aka mod_rewrite) only available in C and goofy to use. This was once an add on module for AOlserver, now it is part of the Tcl API: ns_internalredirect. It seems if we got those things done we could then consider other cool ideas, e.g., new language support (js, php) which shares the adp output buffer so you could mix-match, better integration with memcached, etc. The largest risk of AOLserver falling behind and being dropped is if the codebase doesn't keep up with any changes to Tcl. Other efforts, like adding new languages (except maybe the js spidermonkey) seem more likely to fracture the synergy with the Tcl community. Another risk is the internal, core development. If AOL has not take up 4.5, then this is an indication that performance is good enough. John Buckman's benchmarking seems to indicate that performance is great. Although it is easy to just let whoever has time to commit changes to the core code, this is an issue which really needs to be addressed. Bug fixes are an obvious exception, but not every feature must be included in the core code. The rewrite command above was originally provided as a module. So I think we need a list or set of guidelines on what core changes are acceptable. Obviously internal API changes, data structures, etc. will require core changes, but just adding in a few lines here or there to support a single feature should be discussed quite a bit. Why can't a module work? Maybe the core change should be that which allows the feature to be added as a module. For large scale API or data structure changes, we need an isolation of this development code from the current production code. We can no longer rely on the fact that AOL will have the manpower or will to finish up anything that gets started. Using the sourceforge cvs as a private code repository for any and all development needs to be stopped. Developers really need to feel responsible for not breaking other user's code. This is not cool, and will very quickly drive users away. Who wants to invest their time if the next release will not work for them? If this is not an important issue for the developer, maybe they can learn to make their own private codebase. It is just not a valid argument that since the developer put in the time, they have any right to force their code changes upon the community. Is it time to bucket these ideas and vote on what, if anything, to do? I think there needs to be a community process which respects the current user base and the code that runs on the current core. This is an investment. All the users here have overcome all of the things we wish others to overcome to join our community. However, if the first thing we offer our new guests is our willingness to trash our existing users' investment, who will feel safe that their decision is a good one? If our diminishing resources are divided up on entertaining our new guests who speak in another language, who is going to benefit from that? The new users ask a php question. Who is here to respond? It is not just a question of programming time. This is community time, community resources. If my hour of time requires the community to spend 8 hours, have I helped anyone? 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 focus
Op Thu, 9 Aug 2007, schreef Tom Jackson: On Thursday 09 August 2007 08:46, Jim Davidson wrote: Otherwise, technically there are a few things that could be fixed to solve some pain points: -- Close the gap between AOLserver's init framework and Tcl's package framework so tcllib, ActiveState Tcl, etc. can be used easily (needs those things to be verified, compiled, and available thread-safe) More integration with the Tcl community is important. Both communities have added to the other. What are the issues? What would be the result of closing the gap? -- Figure out some AOLserver-as-an-Apache extension thing -- perhaps a more convenient proxy (seems possible) or a direct Apache module (possible but perhaps too incompatible and goofy to be useful). I have never been able to put my finger on what the issue is here. AOLserver isn't Apache. Sendmail isn't Qmail either. Both compete over a single privileged port. That is the real issue. Some company only has one IP address and needs to make a choice. Then just run AOLserver on an internal IP and proxy through to it. That is the module. Call AOLserver an application server and Apache a firewall. Nobody is complaining that Oracle doesn't run inside AOLserver or Apache, what difference does it make if your application server is a separate process, maybe on a separate machine. Really it is a benefit, a security feature. With an Apache module, you could: * Get AOLserver without dusturbing other users. You could even ask your hoster to install the module. * There is no trouble like all connections coming from the same IP. You have access to the real http connection (through Apache though). So, I think, this would be a big advantage over a proxy solution, even though the proxy solution can work well in a lot of situations. Besides this, AOLserver needs to get better in replacing Apache as the primary web server on a system, and this means getting multi-user capabilities itself. Depending on the way it is done, it can be low hanging fruit too. Daniël -- 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 focus
On Thursday 09 August 2007 11:28, Daniël Mantione wrote: With an Apache module, you could: * Get AOLserver without dusturbing other users. You could even ask your hoster to install the module. * There is no trouble like all connections coming from the same IP. You have access to the real http connection (through Apache though). So, I think, this would be a big advantage over a proxy solution, even though the proxy solution can work well in a lot of situations. Besides this, AOLserver needs to get better in replacing Apache as the primary web server on a system, and this means getting multi-user capabilities itself. Depending on the way it is done, it can be low hanging fruit too. There is no question that it would be easier in the low end market to have a module for Apache. It would save you a few buck on hosting. How much community effort should go into saving a few bucks? I am not saying that if such a thing appeared all by itself more people wouldn't use it. Could it not be just as easy to convince your hoster to proxy to a user space AOLserver? After all, once you have AOLserver installed, you might want to use a database, or install other modules or change the configuration. Do you now need to bug your hoster every time you want to change a configuration? This model seems to require that a new user convince themselves to use AOLserver, then convince their hoster to handle the installation. And the hoster isn't getting paid very much, if anything, for the trouble. Somehow I think that years of effort could go into transforming AOLserver into an Apache clone, but it still isn't Apache. Nobody is dissatisfied with Apache for the problem space AOLserver would need to move into. AOLserver has multi-user capabilities on a system. Each user can run as many AOLservers as they want. What they can't do is all use the same ip:port. Just get another ip and problem solved. Also, for static content, AOLserver can easliy work as a mass hosting solution. The main issue is you can't give a bunch of independent users a chance to execute Tcl commands, maybe you could delete some of the Tcl API and make it safe, that would be another possibility. Someone suggested multi-user really means multi-process. So this might be a question of operating system support. Is it possible? 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 focus
Nobody can argue that better isn't better. There are certain things which seem difficult in AOLserver, maybe more difficult than they should be, but maybe not. One is writing a new C module. I've done some where I use a shared .so module for the interesting library code, and I think I have used a static .la (or whatever it is) file. The difficulty seems to be in using the Tcl C API to make a place to store application data, like handle pointers, etc. Maybe this is just as hard in Apache? Being able to more easily reuse existing C libraries would provide a long term benefit. Maybe this would be easier with ns_proxy and a single threaded/isolated process. Another issue related to C modules is that you can load libnsd into a tcl interp, or just run nstclsh. But you can't load modules, or at least I don't know how to do it. It would probably take a lot of work to get nsd to run as a server inside a tclsh, but what about being able to run nsd with no servers, maybe with Tk as the face of the process, maybe a new main function called nstk. Seems complicated to do, maybe just a module needs to be written that could startup a Tk thread? Being able to use the database and scheduling APIs in a desktop application would be an intesting new area for the AOLserver codebase. Maybe there is something already in this area with Tcl/Postgres/Oracle/etc? tom jackson On Thursday 09 August 2007 11:28, Daniël Mantione wrote: Besides this, AOLserver needs to get better in replacing Apache as the primary web server on a system, and this means getting multi-user capabilities itself. Depending on the way it is done, it can be low hanging fruit too. -- 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 focus
On 10 Aug 2007, at 02:54, Tom Jackson wrote: I have never been able to put my finger on what the issue is here. AOLserver isn't Apache. Sendmail isn't Qmail either. Both compete over a single privileged port. That is the real issue. Some company only has one IP address and needs to make a choice. Then just run AOLserver on an internal IP and proxy through to it. That is the module. Call AOLserver an application server A perfectly viable way of running, I agree; that is not the reason I would like to see such a module. Let's step into the mind of Joe Newbie: ...hmmm, wat's this thing, AOLserver, let's see. apt-get install apache2-mod-aolserver. OK, so no I create a .adp page with some Tcl code. Cool, but I can do that in PHP too. Ah, I see, I create a database pool in my .htaccess file and can use it anywhere by name, neat! And so if I put a procedure in this init.tcl file, it is available anywhere, without the need for stupid include directives on every adp page and recompiling the same code over and over again. Nice. Lets benchmark this thing. Huh? The same code and database calls run how much faster than my PHP version!? I know in the case of debian, AOLserver 4.0.10 is available in stable, but someone with an Apache mindset probably wouldn't find or try it. Plus the configuration of it would be much closer to Apache's. (yes, mod-aolserver would probably need to give up the extreme fine tuning it can do now, but how many people really need that anyway?) Bas. -- 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 focus
Jay,
Have you looked at ns_ictl to see what the relationship is between this and
what you are doing? Somehow I think that ns_ictl does a lot of this type of
thing, but there are no examples of use.
I have complained about the changes to ns_atclose which now requires a conn to
work, and the response has been that ns_ictl should be used instead. I have
not spent the time to figure out how. Somehow this depends on internal code,
maybe ns_ictl could be modified to print (log debug) whenever a state has
changed, which would trigger any code registered via ns_ictl. Then it might
be easy to run tests to see if actions happen at the right point.
The idea of converting (I guess that is the idea) modules into Tcl packages
sounds helpful. Modules seem more difficult than packages. First, there is
configuration information. One thing missing from Tcl is a centralized
configuration and logging facility. What happens instead is that you import a
package into your script and handle things as you like. Maybe this is one
more thing that AOLserver could provide to Tcl, some kind of
configuration/management/monitoring framework. Obviously it is not needed for
simple scripts, and we can't get the configuration stuff yet in libnsd.
I also changed a few things in the nstclsh code, now I have an nswish with
everything in nstclsh+wish. It seems like this could be further modified to
load a config file. Even if AOLserver C modules cannot be loaded, the config
could be used for Tcl packages (even specify which ones to load).
tom jackson
On Thursday 09 August 2007 15:35, Jay Rohr wrote:
Using TCL packages solves a lot of the problems, however there are some
issues that need to be managed within an nsd. I have a number of
AOLservers instances that have a very minimum init file and a single tcl
modules file that only has a single package require to start, load (TCL
and binary packages), and initialize a complete AOLserver instance.
The issue is that the package information, (both TCL and binary) is
stored within the TCL binary code and the AOLserver cloning does not
maintain it. I have written an ns_package package :-) that overrides the
TCL package command to track this information and updated it when a new
interp is created. This works with both 4.0.10 and 4.5. The packages
loaded must be thread safe to work. I have used, tdom, curl, and home
grown and 3rd party TCL and binary packages.
It also handles the automatic calling of package procedures during server
startup and shutdown if they are defined in the package. {package}::nsInit
is called immediately after the package is loaded, {package}::nsPostInit is
called (in load order) after the server startup has completed and a fully
defined interp is ready. {package}::nsShutdown is called (in reverse load
order) at server shutdown. In 4.5, it could also be set to call
procedures are interp allocate, conn, conn close, and deallocate. Modules
could easily (I think) be converted to packages.
Some people (just trying to get it on the table for discussion) do not
like the fact that I overloaded the TCL package command, but I think it
makes the integration and management of third party packages easier and
natural.
--
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 focus
Tom Jackson wrote:
Jay,
Have you looked at ns_ictl to see what the relationship is between this and
what you are doing? Somehow I think that ns_ictl does a lot of this type of
thing, but there are no examples of use.
The ns_package uses ns_ictl oninit to set the package info in a new
interp. The 4.5 ns_ictl package procedure does a package require on
allocate, which can have additional side effects since the package is
actually reload in each interp when the interp is allocated,
I have complained about the changes to ns_atclose which now requires a conn to
work, and the response has been that ns_ictl should be used instead. I have
not spent the time to figure out how. Somehow this depends on internal code,
maybe ns_ictl could be modified to print (log debug) whenever a state has
changed, which would trigger any code registered via ns_ictl. Then it might
be easy to run tests to see if actions happen at the right point.
With 4.5, you now have ns_ictl trace
"create|delete|allocate|deallocate|getconn|freeconn" so that you can
set you own scripts at any point. I have had problems with ns_atclose
causing core faults even in 4.0.10 (but it could have been related to
the specific build paltform)
The idea of converting (I guess that is the idea) modules into Tcl packages
sounds helpful. Modules seem more difficult than packages. First, there is
configuration information. One thing missing from Tcl is a centralized
configuration and logging facility. What happens instead is that you import a
package into your script and handle things as you like. Maybe this is one
more thing that AOLserver could provide to Tcl, some kind of
configuration/management/monitoring framework. Obviously it is not needed for
simple scripts, and we can't get the configuration stuff yet in libnsd.
I also changed a few things in the nstclsh code, now I have an nswish with
everything in nstclsh+wish. It seems like this could be further modified to
load a config file. Even if AOLserver C modules cannot be loaded, the config
could be used for Tcl packages (even specify which ones to load).
tom jackson
On Thursday 09 August 2007 15:35, Jay Rohr wrote:
Using TCL packages solves a lot of the problems, however there are some
issues that need to be managed within an nsd. I have a number of
AOLservers instances that have a very minimum init file and a single tcl
modules file that only has a single "package require" to start, load (TCL
and binary packages), and initialize a complete AOLserver instance.
The "issue" is that the package information, (both TCL and binary) is
stored within the TCL binary code and the AOLserver cloning does not
maintain it. I have written an ns_package package :-) that overrides the
TCL package command to track this information and updated it when a new
interp is created. This works with both 4.0.10 and 4.5. The packages
loaded must be thread safe to work. I have used, tdom, curl, and home
grown and 3rd party TCL and binary packages.
It also handles the automatic calling of package procedures during server
startup and shutdown if they are defined in the package. {package}::nsInit
is called immediately after the package is loaded, {package}::nsPostInit is
called (in load order) after the server startup has completed and a fully
defined interp is ready. {package}::nsShutdown is called (in reverse load
order) at server shutdown. In 4.5, it could also be set to call
procedures are interp allocate, conn, conn close, and deallocate. Modules
could easily (I think) be converted to packages.
Some people (just trying to get it on the table for discussion) do not
like the fact that I overloaded the TCL package command, but I think it
makes the integration and management of third party packages easier and
natural.
--
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.
begin:vcard
fn:Jay J. Rohr
n:Rohr;Jay
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard
Re: [AOLSERVER] aolserver focus
On 8 Aug 2007, at 14:08, Tom Jackson wrote: general indications? Uhhh, I mean what is memcache, how do you use it and why is it useful? Otherwise, it isn't useful to me or anyone else without a clue. http://www.danga.com/memcached/ is brilliant. I have not used it in AOLserver yet, though. There is a Tcl only client but for best performance you'd probably be best off creating a module using one of the C libraries available. Cheers, Bas. -- 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 focus
On 2007.08.07, John Buckman [EMAIL PROTECTED] wrote: I use AOLserver + lighthttpd on the same machine, different IPs, so that mp3s and GIF/JPEGs are fed off lighthttpd, which is stupid and very fast (it's wikipedia's media server) Out of curiousity--have you benchmarked lighttpd vs. AOLserver (since you already have both set up)? AOL replaced their ArtBlaster (very thin, lightweight, single-threaded HTTP server for static assets) a while back and replaced it with AOLserver 4.0, since it was fast enough ... if lighttpd's benchmarks are significantly better, I'd like to try and understand why/how and start tuning AOLserver to match. I'd just like to know if folks are running lighttpd because it truly is faster, or simply because it isn't AOLserver ... Yes, two yeasr ago I did 3 benchmarks, with CGI, small GIF image, and large mp3. I also compared aolserver to a simple all-tcl single threaded web server which I obtained off the tcl wiki. All benchmarks below were on a powerpc mac mini, two years ago, with ab and 10 simultaneous queries. 900 byte image fetch benchmark: --- apache img fetch: 593 /s aolserver img fetch: between 1019 and 1267/s lighthttp img fetch: 1089/s mathopd img fetch: 900/s tclhttpd: 69/s trivial http w/image cache: 1127/s This big surprises were how well aolserver did on small images, as well as the all-tcl web server. requests per second handled with trivial tcl dynamic web page (hello world): --- lighttpd-cgi: 15/second tclhttpd: 32/s apache/php: 120/s aolserver: between 640/s and 750/s trivial all-tcl-web-server http://wiki.tcl.tk/15244: 1162/s Unfortunately, I don't have any notes on the large image benchmark, but let me put some numbers in from memory: 1mb image fetch benchmark: --- apache img fetch: 33 /s aolserver img fetch: around 400/s mathopd img fetch: 750/s lighthttp img fetch: 900/s tclhttpd: 3/s -- as far as what lighthttpd and mathopd are doing to get better speeds, is that they both are not multithreaded, they are just a single async loop, serving static files. I remember that this was an option in Aolserver v2, but I believe it went away in v3. The async sending feature really only kicks the performance up with large files that require many writes to a socket. For small files that fit inside 4k, aolserver is really fast. What my benchmarks found is that except for possibly java-based web servers, nothing comes close to aolserver's performance for web- application building. For small images, aolserver is competitive with lighthttpd. It's only with large files that the async-event- loop approach yields better results. One other note, is that mathopd/lighthttp use less than 5% of the CPU running the large image benchmark. Mathopd also had an option to use SendFile() (which is no longer available on linux) which offloaded most of the work to the kernel. I'm including my trivial all-tcl http server, just for reference. What surprised me was how badly performing tclhttpd was in all benchmarks, vs this all-tcl server design. -john -- 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. ht.tcl Description: Binary data
Re: [AOLSERVER] aolserver focus
Op Tue, 7 Aug 2007, schreef Dossy Shiobara: Hold on a second--define superior, please. I see absolutely no reason to run a separate nsd process per user, giving you full process isolation instead of this uid-juggling stuff that Apache does. With Apache, if you want to make a server config change, you have to bounce the whole process which affects all users. If you run a separate nsd per user, each individual user is isolated from each other completely--including server restarts. If they all need to share the same IP/port, sit a reverse proxy (Pound, Squid, Perlbal, etc.) on that port and have it proxy requests to the appropriate nsd bound to its own separate port. Sure, there's going to be some overhead (the proxy) but it gives you the ultimate in flexibility--especially if the proxy can be reconfigured at runtime without a restart. Ok, practical example: We have a server, two users want to run OpenACS, and 20 users simply wants to code PHP/MySQL. Proposal to the system administrator: Put pound on Port 80 and have requests for the two OpenACS users redirected to their own AOLserver process. Now, everyone on the server will see all requests coming from localhost. Big chance is the PHP/MySQL users won't like that and put the argument just use what everyone else uses in place against the OpenACS users. The net here is that AOLserver really isn't designed to be used by commodity web resellers who host thousands of tiny sites on a single box. Commodity resellers are an extreme example of a multi-user environment. There are many web servers in use that have a much smaller amount of users, like a company that has a webserver where some its developers can develop in their own user web space, students that run a web server together on their campus internet connection, etc. Note that it's suitability for multi-user environments is the single reason why Apache did beat IIS. It is the reason Linux is so dominant in web serving. For non-trivial web applications, you're already going to need to have some reasonably complex web infrastructure (load balancers, caching proxies and CDNs, etc.) in place--and as a cog in that larger machinery, AOLserver certainly solves a set of problems nicely. Definately. Daniël -- 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 focus
Tom Jackson wrote: Jeff, I cut out what I said, but believe me I have never made an argument that Apache was better than AOLserver for anything other than extreme mass hosting of cgi style applications. If you look at the technology and underlying architecture, I don't think it's even necessarily superior in this particular domain. What it definitely has is momentum and mindshare. If you eliminate fastcgi, maybe you could consider them even, I don't know. But there will always be a difference between the models: AOLserver is single, long running process. Apache can start a new process with any uid/gid for every request. So Apache can start up very quickly, AOLserver startup has an additive startup time. This is a fact, not a criticism. I'm not interested in mass hosting or beating Apache in this category. Apache can start a new process with any uid/gid only through a wrapper program, and a proxy too in the case of the worker mpm. Which is not all that different from what aolserver would need to do if someone wanted that functionality. suexec is AFAIU a stand-alone wrapper and could be reused without change; nsproxy takes care of the lightweight forking part. Really the only hard part is the if someone wanted which doesn't appear to be forthcoming. -J -- 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 focus
Bas Scheffers wrote: http://www.danga.com/memcached/ is brilliant. I have not used it in AOLserver yet, though. There is a Tcl only client but for best performance you'd probably be best off creating a module using one of the C libraries available. When I last tried memcached, I used the tclmemcached client, which links against a C library (libmemcache). The problem was that it didn't pool the connections to memcached, but opens a new connection for each request and was not very good at recycling them. This caused some problems on my system. Is there a solution to this problem? (I was just a memcached neophyte, so it might be something obvious.) /Guan -- 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 focus
Daniël Mantione wrote: Ok, practical example: We have a server, two users want to run OpenACS, and 20 users simply wants to code PHP/MySQL. Proposal to the system administrator: Put pound on Port 80 and have requests for the two OpenACS users redirected to their own AOLserver process. Now, everyone on the server will see all requests coming from localhost. Big chance is the PHP/MySQL users won't like that and put the argument just use what everyone else uses in place against the OpenACS users. Lots of proxies support adding in additional http headers to indicate that it is a proxied request. In certain environments (firewalled corporate paranoia) you can't avoid everything being proxied and must deal with this. And more to the point, there are simple ways (about 4 lines of code in a PerlFixupHandler) to recover the proxied connection address from such an added-in header if people are really upset about it. Or as an alternate answer: use apache itself as the proxy. The poor saps who subject themselves to PHP will be happy and the OACS users can have a real system to work with. Obnoxious alternate answer 2: tell the php users, sorry, there's people doing real work on this system. :) Bottom line is, there's no reason why they can't coexist peacefully. -J -- 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 focus
Dossy Shiobara wrote: http://panoptic.com/wiki/aolserver/AOLserver_Cookbook#Server-side_Includes I'm only half-joking here--that code I threw up on the wiki was written and tested very, very briefly as a proof-of-concept and only handles the include SSI tag ... it uses a registered ADP tag for its implementation and is likely dangerous to use as-is, but for anyone who wants to bravely add SSI support to AOLserver, it's probably a good starting point. I have some more thorough code for processing SSIs that does the parsing directly, if anyone else needs to do this. I'd need to clean it up a bit before letting anyone else use it; it's in production, just not production quality, if you know what I mean :/ -J -- 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 focus
Or as an alternate answer: use apache itself as the proxy. The poor saps who subject themselves to PHP will be happy and the OACS users can have a real system to work with. Are there any caching proxy plugins for aolserver? I have cheap bandwidth in other countries, which I'd like to load balance media file serving to. I've used squid in the past, but its algorithm is impenetrable, and I didn't see the bandwidth savings I thought I should. Something like this: a) receive http request b) is file available locally? b1) YES: return the file b2) NO: return HTTP redirect, and get the file from the source, so it's available for the next request c) are we out of disk space? if so, delete the least used file(s) Obviously, a very easy algorithm to write, and I was thinking of using aolserver to do this -john -- 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 focus
Op Wed, 8 Aug 2007, schreef 'Jesus' Jeff Rogers: Daniël Mantione wrote: Ok, practical example: We have a server, two users want to run OpenACS, and 20 users simply wants to code PHP/MySQL. Proposal to the system administrator: Put pound on Port 80 and have requests for the two OpenACS users redirected to their own AOLserver process. Now, everyone on the server will see all requests coming from localhost. Big chance is the PHP/MySQL users won't like that and put the argument just use what everyone else uses in place against the OpenACS users. Lots of proxies support adding in additional http headers to indicate that it is a proxied request. In certain environments (firewalled corporate paranoia) you can't avoid everything being proxied and must deal with this. And more to the point, there are simple ways (about 4 lines of code in a PerlFixupHandler) to recover the proxied connection address from such an added-in header if people are really upset about it. Again, a practical situation: How many PHP packages support such headers? (Even OpenACS doesn't support them, so you would have to fix OpenACS too.) Can you (socially) convince those users to rewrite the PHP apps for you to use your OpenACS? Technically it ain't a problem (and there a lot of smart users on this list who know how to solve technical problems). But, I'm convinced that if want to understand why AOLserver is less popular you do not need to search on the technical defficiencies, not in the marketing either (how many open source projects do marketing), but in the interaction between the the technical behaviour of the program and the social/political environment. Daniël -- 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] memcached (was: Re: [AOLSERVER] aolserver focus)
I don't think you can solve it in libmemcached, it seems to always open and close. You can pool requests, but that would be annoying with a page full of elements, I would say. http://www.outoforder.cc/projects/libs/apr_memcache/ does use configurable pooling and would be my choice for AOLserver. I would not use it as a Tcl module, but rather as a proper AOLserver module that exposes Tcl commands. That way you can integrate it in such a way that it is shared between all interps and config is done in the main config files. (pools and servers) Bas. On 8 Aug 2007, at 17:19, Guan Yang wrote: Bas Scheffers wrote: http://www.danga.com/memcached/ is brilliant. I have not used it in AOLserver yet, though. There is a Tcl only client but for best performance you'd probably be best off creating a module using one of the C libraries available. When I last tried memcached, I used the tclmemcached client, which links against a C library (libmemcache). The problem was that it didn't pool the connections to memcached, but opens a new connection for each request and was not very good at recycling them. This caused some problems on my system. Is there a solution to this problem? (I was just a memcached neophyte, so it might be something obvious.) /Guan -- 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 focus
Daniël Mantione wrote: Again, a practical situation: How many PHP packages support such headers? (Even OpenACS doesn't support them, so you would have to fix OpenACS too.) Can you (socially) convince those users to rewrite the PHP apps for you to use your OpenACS? As a practical solution, if you needed to do it transparently you'd install a trivial C module to patch the request_rec or Conn and change the peer address to the value given in the proxy header. PHP or OACS wouldn't know the difference. In apache if you have mod_perl installed this is very easy (the C module boilerplace would be 5x the size of the actual code for the module). As for AS, I believe this was done in one or more of the old proxy modules; I don't know offhand exactly what it would be but I'm confident its not at all difficult. What you say about the social problem is very true of course - it takes a whole lot of technical wizardry to overcome the inertia of I don't know that system. -J -- 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 focus
Daniël Mantione schrieb:
Again, a practical situation: How many PHP packages support such headers?
(Even OpenACS doesn't support them, so you would have to fix OpenACS too.)
i am not sure, where this discussion is supposed to lead to. A couple of
years ago, i argued
here on the list to have support on the aolserver side for exactly this
task. The
argument was, it is simple enough to do it on the application layer, no
need for direct
support in aolserver. Up to a certain point, this was true, i ended up
with te following
code for openacs, which maintains its own variant of ns_conn.
ad_conn -set peer_addr [ns_conn peeraddr]
if { [ns_config -bool ns/parameters ReverseProxyMode 0] } {
set addr [lindex [ns_set iget [ns_conn headers] x-forwarded-for] end]
if {[string length $addr] 0} {
ad_conn -set peeraddr $addr
}
}
two points:
a) i still believe, that a aolserver newbies (if this species exists) will
have troubles to handle this case: they rather look for a configure
option than for a doit-yourself solution
b) the power of aolserver + tcl is that once it is done it works
for all apps, no need to load a certain PHP/Perl/Ruby/... modules
etc. Having Tcl as a basic glue language ensures that e.g. the
loaded modules work together, which is in a multi-language environment
not always the case
Can you (socially) convince those users to rewrite the PHP apps for you to
use your OpenACS?
most certainly not. It is as well not easy the other way around.
To achieve good code, this is most likely a complete re-design
matching the framework.
-gustaf
--
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 focus
Op Wed, 8 Aug 2007, schreef Gustaf Neumann: Daniël Mantione schrieb: Again, a practical situation: How many PHP packages support such headers? (Even OpenACS doesn't support them, so you would have to fix OpenACS too.) i am not sure, where this discussion is supposed to lead to. A couple of years ago, i argued here on the list to have support on the aolserver side for exactly this task. ... two points: a) i still believe, that a aolserver newbies (if this species exists) will have troubles to handle this case: they rather look for a configure option than for a doit-yourself solution Indeed. As this is a very common situation to AOLserver users, this one area that can be worked on in the batteries included philosophy. Daniël -- 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 focus
I predict that AOLServer will be gone within 10 years. Maybe 5 years. People will say: It was really good software. I do not know what happened. It does not have to turn out that way. This is the second time in a year or so that I have seen this discussion on this list. It always generates a lot of activity and emotion. I believe that this is an indication that AOLServer is in its death throes. My friends, it does not have to turn out that way. The problem with AOLServer is not technical. It is not related to the people who work hard and unselfishly to develop the software. It is not because it is lacking in features. Instead, the problem is that it is not accessible. Consider this: Junior Programmer, the IT guy at a non-profit, has been given the task of setting up a web site that is easy to update, has a calendar and event function, has a restricted area for board members to access meeting reports, and allows users to register to receive a newsletter delivered by email. Junior has installed the latest version of Linux on his server. The installation software guided him through the process and he bought a book that served as a reference. (You will be shocked to learn that most people who manage servers are not programming geniuses.). He installed qMail by downloading the software and following the guidance in the qMail book he bought and by going to the qMail web site where there are detailed instructions covering the installation of the software. He installed D. J. Bernstein's daemntools software by following the detailed instructions on the web site. Now, he wants to run a web server. He knows about Apache and has heard about AOLServer. So, he Googles Installing Apache and Installing AOLServer. Guess which server software Junior decides to use. It is not AOLServer. I think most people will agree that the popular and influential religions all have a written document that explains themselves to potential clients. The same is true for open source server software. Several years ago there was talk about an AOLServer book. It never materialized. If you want this software to have a chance of surviving, you need to write a document that explains the software to the unwashed masses. It does not have to be exhaustive. Keep the 80:20 rule in mind: most people will use only 20 percent of the software's features. Figure out what those are and address them thoroughly. Leave the rest to the developers and those with special needs. Here is a starting point: 1. Introduction Tell people what AOLServer does and how great it is. When they finish this chapter, they should be convinced that this is the way to go. 2. History AOLServer has a history. Tell people what it is. The history will establish its bone fides and help sell the software. 3. Installation This needs to be very detailed (remember Junior Programmer). Show how to install the software on the major variants of Linux, MS Windows, and Mac OS. Leave out the obscure operating systems. Cover every step. Do not assume that Junior knows anything. Tell Junior what folders to create and where to create them (Programming Geniuses will know that they can do whatever they want, but Junior is nervous and wants to have his hand held.) Cover troubleshooting issues. You cannot cover everything, but there are some common errors that should be discussed. Give instructions on how to test the software. 4. Review the essential features Do not just list them and assume that Junior will figure it out. Go into detail and give examples. Provide a complete list of configuration parameters and explain how to use them Cover ns_ functions. Talk about how to use them. Cover tcl and its integration with AOLServer. Again, give examples. There are others. Cover them. 5. Show how to use AOLServer to build web pages - that is what a web server is for This may be obvious, but including this is important. Static web pages Static and Dynamic web pages with tcl Dynamic web pages with adp The more examples, the better. 6. Cover the features everyone uses - this is the 20 percent of features Cover how to connect to a database. Give examples. Cover https. Give examples. Cover virtual servers. Give examples. There are more. Give lots of examples. 7. Advanced features Talk about how to create c modules Talk about how to contribute to the software Talk about advanced features That is it. I am sure that I missed some things, but you get the picture. Some of you will note that a lot of this information is out there. That is probably true. The problem is that there is not a single source for this information. Plus, as new versions of the software have come out, the documentation has not caught up. The unwashed masses want things to be accessible. Make it so, and they are more likely to use it. As long as it is hard to use, no one will use it.
Re: [AOLSERVER] aolserver focus
Op Tue, 7 Aug 2007, schreef Bas Scheffers: all layers are easily interchangeable. You can use Apache + MySQL with Perl, Python or Ruby. You can use Perl/Python/Ruby with Postgresql or I think that is hitting the nail on the head: You can use Apache + MySQL People think web development and they think Apache, not in the least because that is what every hosting company offers. The language is probably second and depends on what runs well inside Apache. Unfortunately that would be PHP. Don't underestimate the power of free advertising through URLs. Every url in .php is an advert for PHP, showing the world what everyone uses for his website. TCL is not the problem, it is a great language and superior to PHP. No need to excuse yourself for using the superior solutions. I think a few reasons contribute to the low popularity of AOLserver * It interoperates badly with Apache. Both need port 80. While solutions exits, none is ideal, and none come with Batteries included. Many people (most) cannot rely 100% on AOLserver, despite ocnsidering it superior for web development. * It is bad in multi-user environments. You cannot give every use his own space to develop his website in. Actually this problem seems easy to solve, since AOLserver can run multiple instances of itself since 4.0. * Nobody pushes the development. While AOLserver is maintained and has even nice new features since 4.5, there are few releases and less progress than other web solutions. Despite this, AOLservers superior design still counts a lot. * Despite open source, development happens behind closed doors. Rather than contributing people wanting to develop start projects like opennsd and naviserver. This is a terrible waste of development recources. Daniël Mantione -- 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 focus
On 2007.08.07, Bas Scheffers [EMAIL PROTECTED] wrote: I always shake my head when this lets implement PHP/Ruby/TechDuJour in AOLserver, that will make it popular comes up. First of all everyone seems to find that only Tcl is any good a threading, so you can't make other languages fit properly. Two thoughts I've been giving a lot of time to, lately: 1) JavaScript: the SpiderMonkey JS engine is thread-safe and I've been integrating it into AOLserver (see: nsjsapi). John Resig has started a small JS library that makes running some client-side JS on the server-side, which I'm hoping to take advantage of. My rationale here is that JS is probably the single web scripting language that is known by the most number of people; regardless of which web stack you use, you're also going to have to use JavaScript. Why not just build the entire web stack with JavaScript, on the client and server side? 2) Lua: Lua seems like the natural successor to Tcl--small, lightweight, simple syntax, and *embeddable*. (FWIW, I don't like Lua's syntax, but who cares.) The folks at Adobe are using it seriously (Adobe Lightroom), game developers are using it (World of Warcraft), etc. Lua's embeddability in threaded applications comes in two flavors: separate Lua States (analogus to Tcl's interp), or new child states which have a shared parent global state (serialized through a global lock). The latter is probably close to what we'd ultimately want for AOLserver in a Tcl_CloneInterp that had shared global state with copy-on-write (COW) and/or global lock semantics. What makes AOLserver AOLserver is the Tcl API; libraries, ns_db and nsv are what makes it better than anything available on Apache. On Apache, lacking nsv's (and nv's), folks use memcache. Naturally, having nsv's out of the box instead of having to figure out and set up memcache makes things simpler. (Yes, memcache is ultimately a whole lot more powerful than AOLserver's nsv's--I know this.) -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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 focus
Daniël Mantione wrote: I think a few reasons contribute to the low popularity of AOLserver * It interoperates badly with Apache. Both need port 80. While solutions exits, none is ideal, and none come with Batteries included. Many people (most) cannot rely 100% on AOLserver, despite ocnsidering it superior for web development. I think this may be more of a marketing issue than a technical one. What does apache do that aolserver doesn't? Ok, there are alot of C modules written for apache. How many of these are in high demand? Other than the programming language ones which others are addressing, I'd guess very few, like mod_auth, mod_include, mod_fastcgi, mod_cgi, and *gag* mod_rewrite. AOLserver can do all of these things just fine, although as you say there is no 'batteries included' modules for handling some of them. * It is bad in multi-user environments. You cannot give every use his own space to develop his website in. Actually this problem seems easy to solve, since AOLserver can run multiple instances of itself since 4.0. You can very easily give each user his own space to develop a website in (e.g., ~/public_html) the only problem is if they want to do things as themself rather than as the aolserver uid, since AFAIK setuid and threads do not interact well. A solution could be built using nsproxy with the proxy running setuid as the desired user and sate interps for user ADPs or something along those lines but it would be a fair amount of work that no one seems to be asking for right now. What do you mean by running multiple instances of itself? Back in the old (3.4) days I used nsvhr to proxy to a few completely separate servers running as separate users which worked mostly ok (there were some lingering networking bugs in nsvhr that I was never able to squash) However the server tends to grow in memory size over time and running multiple independent servers just worsens the problem. -J -- 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 focus
Op Tue, 7 Aug 2007, schreef Jeff Rogers: Daniël Mantione wrote: I think a few reasons contribute to the low popularity of AOLserver * It interoperates badly with Apache. Both need port 80. While solutions exits, none is ideal, and none come with Batteries included. Many people (most) cannot rely 100% on AOLserver, despite ocnsidering it superior for web development. I think this may be more of a marketing issue than a technical one. What does apache do that aolserver doesn't? If have had very few situations that could rely 100% on AOLserver. Be it PHP scripts (yes, I know you can install PHP in AOLserver), multi-user requirements or political issues. Ok, there are alot of C modules written for apache. How many of these are in high demand? Other than the programming language ones which others are addressing, I'd guess very few, like mod_auth, mod_include, mod_fastcgi, mod_cgi, and *gag* mod_rewrite. AOLserver can do all of these things just fine, although as you say there is no 'batteries included' modules for handling some of them. There is no major technical issue with AOLserver. Not at all. The devil is in the details. There are social issues at work (of which some might be addressable with minor technical interventions). * It is bad in multi-user environments. You cannot give every use his own space to develop his website in. Actually this problem seems easy to solve, since AOLserver can run multiple instances of itself since 4.0. You can very easily give each user his own space to develop a website in (e.g., ~/public_html) Correct, I did this on one of my systems. the only problem is if they want to do things as themself rather than as the aolserver uid, since AFAIK setuid and threads do not interact well. ... and there is one TCL library, all databases need to be configured globally, cgi scripts cannot be run with user permissions and more. For multi-user systems, Apache is superior. A solution could be built using nsproxy with the proxy running setuid as the desired user and sate interps for user ADPs or something along those lines but it would be a fair amount of work that no one seems to be asking for right now. Yes, this is one of the solutions. It can technically be done, in multiple ways, it is even doable, but that is not the point. There is competition on port 80, and you need to have a good story to convince your sysadmin (or find concensus in your open source project) to replace Apache with AOLserver on port 80. Again, a social issue. What do you mean by running multiple instances of itself? Back in the old (3.4) days I used nsvhr to proxy to a few completely separate servers running as separate users which worked mostly ok (there were some lingering networking bugs in nsvhr that I was never able to squash) You can have one AOLserver that has multiple configuration files, TCL libraries, ..., each serving a different domain. See http://panoptic.com/wiki/aolserver/Virtual_Hosting Make this implicit (i.e. give a command line option so each user can automatically have his own config file, tcl library, etc.), and installing AOLserver on a server rather than Apache becomes feasible for a hosting provider. However the server tends to grow in memory size over time and running multiple independent servers just worsens the problem. I restart my AOLserver at 04:00 each night, which is enough to elmininate the problem, but this is indeed an issue for current users. I believe it has little to do with popularity, though. Daniël -- 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 focus
Daniël Mantione wrote: I think this may be more of a marketing issue than a technical one. What does apache do that aolserver doesn't? If have had very few situations that could rely 100% on AOLserver. Be it PHP scripts (yes, I know you can install PHP in AOLserver), multi-user requirements or political issues. There is no major technical issue with AOLserver. Not at all. The devil is in the details. There are social issues at work (of which some might be addressable with minor technical interventions). We are in agreement here. This is really the heart of it - it is a social and/or political issue, not a technical one that leads to the poor interoperability. Which is exactly what I said - its a marketing issue. Maybe we (the community) could do the legwork for those technical interventions to address some of those social concerns. Item #1 for such interventions I think would be a apache - aolserver migration guide, not aimed so much at moving a configuration from apache to aolserver (although that would be useful too) as helping an admin who has configured apache previously configure aolserver. the only problem is if they want to do things as themself rather than as the aolserver uid, since AFAIK setuid and threads do not interact well. ... and there is one TCL library, all databases need to be configured globally, cgi scripts cannot be run with user permissions and more. For multi-user systems, Apache is superior. Admittedly its been a long time since I've worked in a highly multi-user environment, but I think these points mostly apply to running external CGI programs, and once you're execing an external progrqam it doesn't matter too much what webserver you're running. For in-process stuff (at least with mod_perl) apache suffers all these same problems, in many cases to a far greater extent. Yes, this is one of the solutions. It can technically be done, in multiple ways, it is even doable, but that is not the point. There is competition on port 80, and you need to have a good story to convince your sysadmin (or find concensus in your open source project) to replace Apache with AOLserver on port 80. Again, a social issue. Again, a marketing problem. It comes down to no one is using it because no one is using it. Idle curiosity - I wonder if anyone is running a system with both apache and aolserver listening on port 80 on different ifs/ips. Should be possible and not even difficult, tho probably of limited utility. -J -- 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 focus
You might also want to try running AOLserver without the Tcl threaded allocator (Zippy). You might want to try Hoard or if on Linux maybe give Google's TCMalloc a shot. Remember, the Zippy allocator is optimized for lock avoidance, and this comes at the cost of greater memory overhead. - n On 8/7/07, Tom Jackson [EMAIL PROTECTED] wrote: None of the issues listed really have a solution. The truth is that if you are doing mass hosting, you should use Apache, the memory footprint is just too great at some point with AOLserver because you have to load each server at startup. At the very least all code for all virtual servers is in memory, at least one copy. Mass hosting of even a hundred domains becomes near impossible. AOLserver cannot be effective in that situation. Apache really is more like sshd, tcpserver, or any other daemon that is just used to startup another process. tom jackson On Tuesday 07 August 2007 11:37, Daniël Mantione wrote: Op Tue, 7 Aug 2007, schreef Jeff Rogers: Daniël Mantione wrote: I think a few reasons contribute to the low popularity of AOLserver * It interoperates badly with Apache. Both need port 80. While solutions exits, none is ideal, and none come with Batteries included. Many people (most) cannot rely 100% on AOLserver, despite ocnsidering it superior for web development. I think this may be more of a marketing issue than a technical one. What does apache do that aolserver doesn't? If have had very few situations that could rely 100% on AOLserver. Be it PHP scripts (yes, I know you can install PHP in AOLserver), multi-user requirements or political issues. Ok, there are alot of C modules written for apache. How many of these are in high demand? Other than the programming language ones which others are addressing, I'd guess very few, like mod_auth, mod_include, mod_fastcgi, mod_cgi, and *gag* mod_rewrite. AOLserver can do all of these things just fine, although as you say there is no 'batteries included' modules for handling some of them. There is no major technical issue with AOLserver. Not at all. The devil is in the details. There are social issues at work (of which some might be addressable with minor technical interventions). * It is bad in multi-user environments. You cannot give every use his own space to develop his website in. Actually this problem seems easy to solve, since AOLserver can run multiple instances of itself since 4.0. You can very easily give each user his own space to develop a website in (e.g., ~/public_html) Correct, I did this on one of my systems. the only problem is if they want to do things as themself rather than as the aolserver uid, since AFAIK setuid and threads do not interact well. ... and there is one TCL library, all databases need to be configured globally, cgi scripts cannot be run with user permissions and more. For multi-user systems, Apache is superior. A solution could be built using nsproxy with the proxy running setuid as the desired user and sate interps for user ADPs or something along those lines but it would be a fair amount of work that no one seems to be asking for right now. Yes, this is one of the solutions. It can technically be done, in multiple ways, it is even doable, but that is not the point. There is competition on port 80, and you need to have a good story to convince your sysadmin (or find concensus in your open source project) to replace Apache with AOLserver on port 80. Again, a social issue. What do you mean by running multiple instances of itself? Back in the old (3.4) days I used nsvhr to proxy to a few completely separate servers running as separate users which worked mostly ok (there were some lingering networking bugs in nsvhr that I was never able to squash) You can have one AOLserver that has multiple configuration files, TCL libraries, ..., each serving a different domain. See http://panoptic.com/wiki/aolserver/Virtual_Hosting Make this implicit (i.e. give a command line option so each user can automatically have his own config file, tcl library, etc.), and installing AOLserver on a server rather than Apache becomes feasible for a hosting provider. However the server tends to grow in memory size over time and running multiple independent servers just worsens the problem. I restart my AOLserver at 04:00 each night, which is enough to elmininate the problem, but this is indeed an issue for current users. I believe it has little to do with popularity, though. Daniël -- 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
Re: [AOLSERVER] aolserver focus
Tom Jackson wrote: None of the issues listed really have a solution. The truth is that if you are doing mass hosting, you should use Apache, the memory footprint is just too great at some point with AOLserver because you have to load each server at startup. At the very least all code for all virtual servers is in memory, at least one copy. Mass hosting of even a hundred domains becomes near impossible. AOLserver cannot be effective in that situation. Apache really is more like sshd, tcpserver, or any other daemon that is just used to startup another process. Mass hosting alot of domains with vastly different setups isn't practical, but hosting lots of domains all configured identically can be done easily, just not with virtual hosts as such. It would need something more along the lines of apache's mod_vhost_alias where parameters for the virtual host are dynamically configured according to rules from a template rather than explicitly. The suggestion from long long ago was to use a custom UrlToFile proc (which sadly can only be done from C code) that is sensitive to the Host header. I'm not trying to be super-advocate boy here, but it just seems like everyone here is making arguments as to why aolserver really isn't good enough compared to apache and it saddens me - if the support community doesn't believe in the product, what chance do I have of convincing my boss next time he wants to shut down that app written in some ancient tcl and aolserver app because its not apache, java, and perl? (to be fair, 3.1 *is* ancient, they're just afraid to let me upgrade it. *sigh*) -J -- 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 focus
Op Tue, 7 Aug 2007, schreef Tom Jackson: None of the issues listed really have a solution. The truth is that if you are doing mass hosting, you should use Apache, the memory footprint is just too great at some point with AOLserver because you have to load each server at startup. At the very least all code for all virtual servers is in memory, at least one copy. Mass hosting of even a hundred domains becomes near impossible. AOLserver cannot be effective in that situation. Apache really is more like sshd, tcpserver, or any other daemon that is just used to startup another process. I agree, but it is fixable. Unused servers could be started an shut down on demand so a web site that receives 5 hits/day doesn't eat memory continuously. However, I am again talking in terms of technical solutions, while the actual thing is to address the social/political problem of AOLserver not being useable in a multi-user environment. A hoster can already sell an AOLserver hosting service if it can serve let's say, 25 users on one server. If each customer that needs AOLserver needs a dedicated server and ip-address, business wise this is a big no no. Daniël -- 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 focus
I have several interfaces, but one of my interfaces is configured with apache on port 80, and several AOLServer instances on other ports. Apache serves some pages/applications itself and forwards the rest to AOLServer. Rusty Daniël Mantione wrote: Op Tue, 7 Aug 2007, schreef Jeff Rogers: Idle curiosity - I wonder if anyone is running a system with both apache and aolserver listening on port 80 on different ifs/ips. Should be possible and not even difficult, tho probably of limited utility. Yes, I have setups like this and is the best solution to this problem. However, in many situations, multiple ip-addresses are unavailable and Apache and AOLserver compete for port 80. Daniël -- 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 focus
Idle curiosity - I wonder if anyone is running a system with both apache and aolserver listening on port 80 on different ifs/ips. Should be possible and not even difficult, tho probably of limited utility. Yes, I have setups like this and is the best solution to this problem. However, in many situations, multiple ip-addresses are unavailable and Apache and AOLserver compete for port 80. I use AOLserver + lighthttpd on the same machine, different IPs, so that mp3s and GIF/JPEGs are fed off lighthttpd, which is stupid and very fast (it's wikipedia's media server) -john -- 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 focus
Op Tue, 7 Aug 2007, schreef Nathan Folkman: You might also want to try running AOLserver without the Tcl threaded allocator (Zippy). You might want to try Hoard or if on Linux maybe give Google's TCMalloc a shot. Remember, the Zippy allocator is optimized for lock avoidance, and this comes at the cost of greater memory overhead. Yup, I have installations where AOLserver uses very little memory. Try this with Apache :) wwwrun4552 0.0 1.4 7380 3612 ?Sl Jul26 2:21 /opt/aolserver/bin/nsd -ft /opt/aolserver/nsd.tcl -u wwwrun Daniël -- 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 focus
Op Tue, 7 Aug 2007, schreef Jeff Rogers: I'm not trying to be super-advocate boy here, but it just seems like everyone here is making arguments as to why aolserver really isn't good enough compared to apache and it saddens me - if the support community doesn't believe in the product, what chance do I have of convincing my boss next time he wants to shut down that app written in some ancient tcl and aolserver app because its not apache, java, and perl? (to be fair, 3.1 *is* ancient, they're just afraid to let me upgrade it. *sigh*) :) Many people here can give you a long list why AOLserver is the best web development platform. None of the issues we discuss are in the line of PHP/Perl/Java is better than TCL, because this simply isn't true. AOLserver, after all those years, is still freaking awesome, which is why I use it. That said, there are reasons why it doesn't conquer the world. Many users on this list, me included, run into those reasons, despite being strong AOLserver advocates. Daniël -- 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 focus
It is possible. ;) There are a number of other things you can do as well to help. One example is configuring your threads such that they die and get reaped after a certain number of requests or time. This will cause memory that is currently tied up in the thread's memory pool to be returned back to the shared memory pool, which can have the net effect of lowering the overall process size. - n On 8/7/07, Daniël Mantione [EMAIL PROTECTED] wrote: Op Tue, 7 Aug 2007, schreef Nathan Folkman: You might also want to try running AOLserver without the Tcl threaded allocator (Zippy). You might want to try Hoard or if on Linux maybe give Google's TCMalloc a shot. Remember, the Zippy allocator is optimized for lock avoidance, and this comes at the cost of greater memory overhead. Yup, I have installations where AOLserver uses very little memory. Try this with Apache :) wwwrun4552 0.0 1.4 7380 3612 ?Sl Jul26 2:21 /opt/aolserver/bin/nsd -ft /opt/aolserver/nsd.tcl -u wwwrun Daniël -- 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. -- Nathan Folkman [EMAIL PROTECTED] -- 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 focus
Over in naviserver Vlad (I think) did a bunch of work on vmalloc which tries to actually release the memory back to the system (rather than just the shared pool) on thread exit to keep the process size smaller still. I don't recall what the ultimate outcome of it was however. -J Nathan Folkman wrote: It is possible. ;) There are a number of other things you can do as well to help. One example is configuring your threads such that they die and get reaped after a certain number of requests or time. This will cause memory that is currently tied up in the thread's memory pool to be returned back to the shared memory pool, which can have the net effect of lowering the overall process size. - n On 8/7/07, Daniël Mantione [EMAIL PROTECTED] wrote: Op Tue, 7 Aug 2007, schreef Nathan Folkman: You might also want to try running AOLserver without the Tcl threaded allocator (Zippy). You might want to try Hoard or if on Linux maybe give Google's TCMalloc a shot. Remember, the Zippy allocator is optimized for lock avoidance, and this comes at the cost of greater memory overhead. Yup, I have installations where AOLserver uses very little memory. Try this with Apache :) wwwrun4552 0.0 1.4 7380 3612 ?Sl Jul26 2:21 /opt/aolserver/bin/nsd -ft /opt/aolserver/nsd.tcl -u wwwrun Daniël -- 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 focus
Daniël Mantione wrote: I'm not to happy to call it a marketing issue, because this suggests that if you would have a big enough advertising campain, you can make AOLserver win from Apache. This is not the case. Software lock-in is very difficult to undo (ever try to get someone to change their preferred text editor? mail tool? word processor? webserver ... ) But it *can* be done. Either through convincing them of the benefits (slow and painful), forcing them (not always possible), or providing something that they cannot get elsewhere (e.g., a new framework, access to the company email, or whatever). I don't really mean marketing as in a public relations campaign (although that certainly wouldn't hurt), I mean it more as education and changing the public perception. How to do that? If I knew I'd probably be rich (or a politician). It is the way you need to work with AOLserver that causes these problems. Not because AOLserver cannot do something (on the contrary, it is one of the most capable web servers), but you run into social/political issues, like you needing port 80, have a user who has a MySQL application in his public_html directory, etc. Ok then, first up on the FUQ list (that's frequently unasked questions): Q: How do I run AOLserver when I already have apache running on port 80? A: There's lots of ways, some of which may not work due to your particular political/social situation. AOLserver can do nearly everything apache can, so you could just drop apache. If you have SSI files, [instructions for SSI support] If you have CGI files, [instructions for CGI support with setuid] If you have PHP apps, [instructions for PHP setup] If you have extensive rewrite rules, [script for changing them to filters] If your sysadmin/company/project is unwilling to move away from apache for everything and you still need to coexist, you could: - run both apache and aolserver on alternate ports behind a reverse proxy - run apache up front and use mod_proxy to proxy particular requests to aolserver running on an alternate port - bind aolserver and apache to different interfaces on port 80 - run aolserver on e.g., port 81 and include that in your urls Any others? Should something like this be on the wiki? -J -- 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 focus
On 2007.08.07, Dani?l Mantione [EMAIL PROTECTED] wrote:
... and there is one TCL library,
There is a shared global Tcl library as well as a per-virtual server Tcl
library. The shared global one is in PREFIX/modules/tcl, while the
per-server Tcl library is configured using:
ns_section ns/server/${servername}/tcl
ns_param library /path/to/server/tcl
Perhaps it's not well-documented (enough) such that people are aware of
it, but it's there.
all databases need to be configured globally,
Indeed, database pool definitions are global. I believe you can
restrict what pools a server has access to, but considering that the
auth. credentials are readable by anyone, it's still a security issue.
cgi scripts cannot be run with user permissions and more. For
multi-user systems, Apache is superior.
Hold on a second--define superior, please. I see absolutely no reason
to run a separate nsd process per user, giving you full process
isolation instead of this uid-juggling stuff that Apache does. With
Apache, if you want to make a server config change, you have to bounce
the whole process which affects all users. If you run a separate nsd
per user, each individual user is isolated from each other
completely--including server restarts.
If they all need to share the same IP/port, sit a reverse proxy (Pound,
Squid, Perlbal, etc.) on that port and have it proxy requests to the
appropriate nsd bound to its own separate port. Sure, there's going to
be some overhead (the proxy) but it gives you the ultimate in
flexibility--especially if the proxy can be reconfigured at runtime
without a restart.
The net here is that AOLserver really isn't designed to be used by
commodity web resellers who host thousands of tiny sites on a single
box. For non-trivial web applications, you're already going to need to
have some reasonably complex web infrastructure (load balancers, caching
proxies and CDNs, etc.) in place--and as a cog in that larger machinery,
AOLserver certainly solves a set of problems nicely.
-- Dossy
--
Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network | http://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 focus
On 2007.08.07, Jeff Rogers [EMAIL PROTECTED] wrote: Idle curiosity - I wonder if anyone is running a system with both apache and aolserver listening on port 80 on different ifs/ips. Should be possible and not even difficult, tho probably of limited utility. I certainly do this--I run Apache2 just for mod_dav_svn to run svn.panoptic.com. The rest of my HTTP traffic is served out of AOLserver. Would I really like a chunk of code to do DAV/SVN under AOLserver? You bet. :-) -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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 focus
On 2007.08.07, John Buckman [EMAIL PROTECTED] wrote: I use AOLserver + lighthttpd on the same machine, different IPs, so that mp3s and GIF/JPEGs are fed off lighthttpd, which is stupid and very fast (it's wikipedia's media server) Out of curiousity--have you benchmarked lighttpd vs. AOLserver (since you already have both set up)? AOL replaced their ArtBlaster (very thin, lightweight, single-threaded HTTP server for static assets) a while back and replaced it with AOLserver 4.0, since it was fast enough ... if lighttpd's benchmarks are significantly better, I'd like to try and understand why/how and start tuning AOLserver to match. I'd just like to know if folks are running lighttpd because it truly is faster, or simply because it isn't AOLserver ... -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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 focus
On 2007.08.07, Jeff Rogers [EMAIL PROTECTED] wrote: Over in naviserver Vlad (I think) did a bunch of work on vmalloc which tries to actually release the memory back to the system (rather than just the shared pool) on thread exit to keep the process size smaller still. I don't recall what the ultimate outcome of it was however. I imagine that's a losing battle as then you start to see all sorts of fragmentation issues, I bet. I'm just guessing here; I'm likely wrong and I'm okay with that--I haven't reviewed any of their code, and I'm sure the behavior will be dependent on the underlying OS's memory management implememtation, as well. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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 focus
On 2007.08.07, Jeff Rogers [EMAIL PROTECTED] wrote: Ok then, first up on the FUQ list (that's frequently unasked questions): Q: How do I run AOLserver when I already have apache running on port 80? A: There's lots of ways, some of which may not work due to your particular political/social situation. AOLserver can do nearly everything apache can, so you could just drop apache. If you have SSI files, [instructions for SSI support] http://panoptic.com/wiki/aolserver/AOLserver_Cookbook#Server-side_Includes I'm only half-joking here--that code I threw up on the wiki was written and tested very, very briefly as a proof-of-concept and only handles the include SSI tag ... it uses a registered ADP tag for its implementation and is likely dangerous to use as-is, but for anyone who wants to bravely add SSI support to AOLserver, it's probably a good starting point. If you have CGI files, [instructions for CGI support with setuid] For per-user CGI support, we could possibly add a setuid-root wrapper like Apache's suEXEC http://httpd.apache.org/docs/1.3/suexec.html. But, for the same reason that Apache doesn't include suEXEC as part of the default installation, I think it'd be foolhardy to make it a default part of AOLserver, as well. But, having support for it might yield some tangible benefits for those poor folks who have to run CGI under AOLserver out there. If you have PHP apps, [instructions for PHP setup] http://panoptic.com/wiki/aolserver/How_to_set_up_PHP_under_AOLserver If you have extensive rewrite rules, [script for changing them to filters] This would be a nice addition to the wiki. Anyone care to help write it? Either that, or should we implement a nsmodrewrite that reads .htaccess files and parses mod_rewrite rules? The big caveat is if you use this, you'll take a performance hit ... ? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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 focus
Jeff, I cut out what I said, but believe me I have never made an argument that Apache was better than AOLserver for anything other than extreme mass hosting of cgi style applications. If you eliminate fastcgi, maybe you could consider them even, I don't know. But there will always be a difference between the models: AOLserver is single, long running process. Apache can start a new process with any uid/gid for every request. So Apache can start up very quickly, AOLserver startup has an additive startup time. This is a fact, not a criticism. I'm not interested in mass hosting or beating Apache in this category. tom jackson On Tuesday 07 August 2007 13:24, Jeff Rogers wrote: I'm not trying to be super-advocate boy here, but it just seems like everyone here is making arguments as to why aolserver really isn't good enough compared to apache and it saddens me -- 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 focus
On 7 Aug 2007, at 23:07, Dossy Shiobara wrote: 1) JavaScript: the SpiderMonkey JS engine is thread-safe and I've been integrating it into AOLserver (see: nsjsapi). John Resig has started I'll have a look at that soon! On Apache, lacking nsv's (and nv's), folks use memcache. Naturally, But wouldn't nsv be possible now in the multi-threaded mpm? memcache makes things simpler. (Yes, memcache is ultimately a whole lot more powerful than AOLserver's nsv's--I know this.) Depends on what you use it for; I use nsv for my translation dictionaries (multi-lingual site); it is a small resource that must be shared between interps and doesn't warrant memcache, but using interpreter namespace variables like msgcat would not be very nice. For caching people's profile or product pages and such, memcache obviously is the best way to go, however. -- 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 focus
On Tuesday 07 August 2007 19:20, Bas Scheffers wrote: For caching people's profile or product pages and such, memcache obviously is the best way to go, however. I'm always interested in how-to stuff. Are there any examples of use, or just general indications? Uhhh, I mean what is memcache, how do you use it and why is it useful? Otherwise, it isn't useful to me or anyone else without a clue. 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 focus
2c about the coupling thing. tcl is certainly unpopular - (put's on flame retardent suit) - it doesn't suit structured programming well like, say, ruby and python do, and it takes more brainpower to keep all those uplevels working. Having said that, PHP is also unsuited to structured programming and MySQL is just unsuitable ;) The realy beauty of the opensource web development stack then is that all layers are easily interchangeable. You can use Apache + MySQL with Perl, Python or Ruby. You can use Perl/Python/Ruby with Postgresql or Oracle and serve the application on Apache or lighttpd, etc. I think the tcl coupling - or rather the inability to couple with other languages easily - is a big problem. Ruby on Rails has shown that people aren't wedded to Apache. Many RoR sites are hosted using alternative servers (like lighttpd). One of the core issues behind the lack of coupling with other languages is in fact that AOLServer is still ahead of the game with threading. I've tried pretty hard at making perl and ruby ns modules - only to be stumped by issues with the weakness of their threading models. One possibility here (and VERY buzzword compliant) is JRuby - where the threading model is that of the JVM. If it turns out to be possible to nicely host, say, JRuby applications on aolserver and give the Ruby code access to aolserver features I think we would find ourselves with a very popular server on our hands. Mark. -- Mark Aufflick contact info at http://mark.aufflick.com/about/contact On 8/4/07, Jim Davidson [EMAIL PROTECTED] wrote: Howdy folks, Seems like we're having another flare-up of frustration on the list... I left AOL about a year ago and haven't had much time to contribute since. I probably wrote (re-wrote and wrote again) 90% of the code and had several teams hacking Tcl code for dozens of AOL web sites over the past 12 years. I think it's a fair criticism we often talked to ourselves within AOL instead of soliciting feedback outside. Why? I don't know -- maybe because we thought the scale of our operations made us different, more likely we were just lazy or distracted -- I think most of my time at AOL took the form of please enter your meeting id number followed by the pound sign Anyway, I've spent some time with LAMPP recently -- quite clever all that PHP/MySql stuff. To compare, AOLserver -- Still has a scalable architecture and good underlying code quality -- Is tightly woven with Tcl which appears less and less popular each year (I could be wrong) -- Is lacking many extensions or has cruddy alternatives (e.g., ns_http instead of curl) -- Has horrible, incomplete, and often misleading documentation -- Isn't so easy to install and configure while lampp: -- Has great documentation with threaded discussions -- Relies on PHP which, fair or unfair, appears quite popular -- Has possibly too many overlapping extensions -- Is hard to install and configure unless you're using that xampp stuff I'm wondering -- does it make sense to just try to close the gap with LAMPP as a model, driving to the batteries-included distro Dossy's been talking about for years? That seems to me like a project tons of folks could contribute too -- from docs to extensions to installers, etc. -Jim -- 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 focus
On 7 Aug 2007, at 13:08, Mark Aufflick wrote: tcl is certainly unpopular - (put's on flame retardent suit) - it doesn't suit structured programming well like, say, ruby and python Those languages were really only made popular by their use in a hot(- ish) new(-ish) web stack, Tcl could achieve the same. all layers are easily interchangeable. You can use Apache + MySQL with Perl, Python or Ruby. You can use Perl/Python/Ruby with Postgresql or I think that is hitting the nail on the head: You can use Apache + MySQL People think web development and they think Apache, not in the least because that is what every hosting company offers. The language is probably second and depends on what runs well inside Apache. Unfortunately that would be PHP. I always shake my head when this lets implement PHP/Ruby/TechDuJour in AOLserver, that will make it popular comes up. First of all everyone seems to find that only Tcl is any good a threading, so you can't make other languages fit properly. (That said, most languages don't fit well in apache; RoR uses lame forked FastCGI) Secondly, I don't care about the AOLserver HTTP layer. Yes, it is fast but so are other web layers. What makes AOLserver AOLserver is the Tcl API; libraries, ns_db and nsv are what makes it better than anything available on Apache. Personally, I would prefer it to run in Apache and have someone else maintain the HTTP layer and being able to have easy, stable virtual servers, mod_rewrite, etc. I know AD did a mod_aolserver at some point but shoehorning a threaded back-end to a forking server was probably never a good idea to begin with. With Apache 2 knowing a thing or two about threading now it might just work a whole lot better. I think the tcl coupling - or rather the inability to couple with other languages easily - is a big problem. Ruby on Rails has shown I agree, except I think it is the other way around; the inability of the Tcl API to run inside anything else than AOLserver. Although it would kill AOLserver as a stand-alone product, I think this is a good model: - AOLserver Tcl API implemented in Apache 2's threaded model. - Including pretty much all of tcllib in the distribution - Same for tdom - create a cool framework. I am not the greatest fan, but they can generate a lot of buzz. A Tcl/ADP clone of WebWork and SiteMesh (http://www.opensymphony.com/) should do fine. You could just have a content handler for .adp files and a config directive can point to the Tcl lib dir. Registered procedures and ADPs would probably have to be done to in config directives but it being apache, all this could be set in .htaccess files for easy (untar and call setup.adp) deployment. Running inside the bloated apache probably won't make it any faster, but it also shouldn't make it unworkably slow at all either. (Yahoo! seems to have embraced PHP for cryin' out loud and they have a page view or two every day...) Just my 2 cents... Cheers, Bas. -- 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 focus
I'm wondering -- does it make sense to just try to close the gap with LAMPP as a model, driving to the batteries-included distro Dossy's been talking about for years? That seems to me like a project tons of folks could contribute too -- from docs to extensions to installers, etc. On new aolserver installations, I install the ActiveState batteries included tcl version, and then copy over all the libraries it has (which is a *lot*) into aolserver's tcl directory (in my case /usr/ local/), which makes for an extremely capable AolServer/tcl distro. hmm.. it might actually be possible to build aolserver against the activestate distro directly to accomplish this. The ActiveState batteries included tcl version competes really well, IMHO, with PHP and Perl. My only issue has been that apparently TclX doesn't play nice with AOLserver and can cause unclean shutdowns (I think Dossy said this), otherwise I have a wide variety of libraries, pretty much all the same stuff as PHP/Perl. -john -- 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 focus
more likely we were just lazy or distracted To paraphrase a famous saying, never attribute to malice what can be attributed to laziness :) (those who know me in the OpenACS project have some idea as to how lazy I am) -- Is tightly woven with Tcl which appears less and less popular each year (I could be wrong) No, you're right, though it has to do with the unpopularity of Tcl rather than the principle of coupling, mostly, I think. -- 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 focus
On new aolserver installations, I install the ActiveState batteries included tcl version, and then copy over all the libraries it has (which is a *lot*) into aolserver's tcl directory (in my case /usr/local/), which makes for an extremely capable AolServer/tcl distro. hmm.. it might actually be possible to build aolserver against the activestate distro directly to accomplish this. The ActiveState batteries included tcl version competes really well, IMHO, with PHP and Perl. My only issue has been that apparently TclX doesn't play nice with AOLserver and can cause unclean shutdowns (I think Dossy said this), otherwise I have a wide variety of libraries, pretty much all the same stuff as PHP/ Perl. I've said before that AOLServer would best be served as a series of modules that leverage standard distributions. In this way it would become more like Ruby on Rails or similar Python frameworks. A more elegant coupling will probably improve things all around. To that end, I can assist with the de/recoupling, although my time resources for me are unfortunately not in abundance. Would it be even possible to have AOLServer as a tcl module, and thus automatically distributed with the batteries included releases? As to the TclX problem ... I wonder if that has to do with mt issues. I don't know if TclX has been fully vetted for thread- safety (and you should most definitely never fork() with threads). Yeah, that would make sense, though it is completely stable for except during shutdown. -john -- 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 focus
John, does this distro's Http package work well within AOLServer? We did a cURL integration for AOLServer 3.4.2, but have been holding off on any contribution because it's very intertwined with our C++ stuff -- and figured that one reason the AOLServer community did all its changes for 4.0 4.5 was to be able to use packages like that. We haven't gotten far enough in our port to 4.5 to have tested the Http package (we've been focused on C/C++ integration, not Tcl, so far). Thanks -- -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of John Buckman Sent: Friday, August 03, 2007 11:01 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] aolserver focus I'm wondering -- does it make sense to just try to close the gap with LAMPP as a model, driving to the batteries-included distro Dossy's been talking about for years? That seems to me like a project tons of folks could contribute too -- from docs to extensions to installers, etc. On new aolserver installations, I install the ActiveState batteries included tcl version, and then copy over all the libraries it has (which is a *lot*) into aolserver's tcl directory (in my case /usr/ local/), which makes for an extremely capable AolServer/tcl distro. hmm.. it might actually be possible to build aolserver against the activestate distro directly to accomplish this. The ActiveState batteries included tcl version competes really well, IMHO, with PHP and Perl. My only issue has been that apparently TclX doesn't play nice with AOLserver and can cause unclean shutdowns (I think Dossy said this), otherwise I have a wide variety of libraries, pretty much all the same stuff as PHP/Perl. -john -- 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 focus
I've been using a stock Tclcurl distro with both 4.0 and 4.5 with no problems. Jay Rick Cobb wrote: John, does this distro's Http package work well within AOLServer? We did a cURL integration for AOLServer 3.4.2, but have been holding off on any contribution because it's very intertwined with our C++ stuff -- and figured that one reason the AOLServer community did all its changes for 4.0 4.5 was to be able to use packages like that. We haven't gotten far enough in our port to 4.5 to have tested the Http package (we've been focused on C/C++ integration, not Tcl, so far). Thanks -- -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of John Buckman Sent: Friday, August 03, 2007 11:01 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] aolserver focus I'm wondering -- does it make sense to just try to close the gap with LAMPP as a model, driving to the batteries-included distro Dossy's been talking about for years? That seems to me like a project tons of folks could contribute too -- from docs to extensions to installers, etc. On new aolserver installations, I install the ActiveState batteries included tcl version, and then copy over all the libraries it has (which is a *lot*) into aolserver's tcl directory (in my case /usr/ local/), which makes for an extremely capable AolServer/tcl distro. hmm.. it might actually be possible to build aolserver against the activestate distro directly to accomplish this. The ActiveState batteries included tcl version competes really well, IMHO, with PHP and Perl. My only issue has been that apparently TclX doesn't play nice with AOLserver and can cause unclean shutdowns (I think Dossy said this), otherwise I have a wide variety of libraries, pretty much all the same stuff as PHP/Perl. -john -- 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. -- 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. begin:vcard fn:Jay J. Rohr n:Rohr;Jay email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Re: [AOLSERVER] aolserver focus
On Aug 3, 2007, at 8:41 PM, Rick Cobb wrote: John, does this distro's Http package work well within AOLServer? We did a cURL integration for AOLServer 3.4.2, but have been holding off on any contribution because it's very intertwined with our C++ stuff -- and figured that one reason the AOLServer community did all its changes for 4.0 4.5 was to be able to use packages like that. We haven't gotten far enough in our port to 4.5 to have tested the Http package (we've been focused on C/C++ integration, not Tcl, so far). Yes, the http package works perfectly inside AOLServer, I use it for Amazon API XML lookups on BookMooch, which is a heavily used feature, so definitely no problems. -john -- 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.
