|
Home > Archive > AOL Webserver > August 2007 > aolserver focus
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Jim Davidson 2007-08-03, 1:11 pm |
| 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
| |
| John Buckman 2007-08-03, 7:11 pm |
| > 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
| |
| dhogaza@PACIFIER.COM 2007-08-03, 7:11 pm |
| > 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.
| |
| Jeff Hobbs 2007-08-03, 7:11 pm |
| John Buckman wrote:
>
> 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.
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).
Jeff
| |
| John Buckman 2007-08-03, 7:11 pm |
| >> On new aolserver installations, I install the ActiveState
>
> 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
| |
| Rick Cobb 2007-08-03, 7:11 pm |
| 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:AOLSERVER@LISTSERV.AOL.COM] 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
<listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
| |
| Jeff Hobbs 2007-08-03, 7:11 pm |
| John Buckman wrote:
>
> Would it be even possible to have AOLServer as a tcl module, and thus
> automatically distributed with the batteries included releases?
Yes, although it would require being used with a threaded Tcl core.
Jeff
| |
| Jay Rohr 2007-08-03, 7:11 pm |
| | |
| John Buckman 2007-08-03, 7:11 pm |
| 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
| |
| Mark Aufflick 2007-08-07, 1:11 am |
| 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 <jgdavidson@mac.com> 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 <listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
>
| |
| Bas Scheffers 2007-08-07, 1:11 am |
| 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.
| |
| Daniël Mantione 2007-08-07, 7:11 am |
| | |
| Dossy Shiobara 2007-08-07, 1:11 pm |
| On 2007.08.07, Bas Scheffers <bas@SCHEFFERS.NET> 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) Java script: 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 | dossy@panoptic.com | 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)
| |
| Jeff Rogers 2007-08-07, 1:11 pm |
| Dani=EBl Mantione wrote:
> I think a few reasons contribute to the low popularity of AOLserver
> * It interoperates badly with Apache. Both need port 80. While solution=
s=20
> 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.=20
What does apache do that aolserver doesn't? Ok, there are alot of C=20
modules written for apache. How many of these are in high demand?=20
Other than the programming language ones which others are addressing,=20
I'd guess very few, like mod_auth, mod_include, mod_fastcgi, mod_cgi,=20
and *gag* mod_rewrite. AOLserver can do all of these things just fine,=20
although as you say there is no 'batteries included' modules for=20
handling some of them.
> * It is bad in multi-user environments. You cannot give every use his o=
wn
> 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=20
(e.g., ~/public_html) the only problem is if they want to do things as=20
themself rather than as the aolserver uid, since AFAIK setuid and=20
threads do not interact well. A solution could be built using nsproxy=20
with the proxy running setuid as the desired user and sate interps for=20
user ADPs or something along those lines but it would be a fair amount=20
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=20
old (3.4) days I used nsvhr to proxy to a few completely separate=20
servers running as separate users which worked mostly ok (there were=20
some lingering networking bugs in nsvhr that I was never able to squash)=20
However the server tends to grow in memory size over time and running=20
multiple independent servers just worsens the problem.
-J
| |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| Jeff Rogers 2007-08-07, 7:11 pm |
| Dani=EBl Mantione wrote:
at does[vbcol=seagreen]
>=20
> If have had very few situations that could rely 100% on AOLserver. Be i=
t=20
> php scripts (yes, I know you can install php in AOLserver), multi-user=20
> requirements or political issues.
>
> There is no major technical issue with AOLserver. Not at all. The devil=
is=20
> in the details. There are social issues at work (of which some might be=
=20
> 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,=20
not a technical one that leads to the poor interoperability. Which is=20
exactly what I said - its a marketing issue.
Maybe we (the community) could do the legwork for those technical=20
interventions to address some of those social concerns. Item #1 for=20
such interventions I think would be a apache -> aolserver migration=20
guide, not aimed so much at moving a configuration from apache to=20
aolserver (although that would be useful too) as helping an admin who=20
has configured apache previously configure aolserver.
ads do[vbcol=seagreen]
>=20
> ... and there is one TCL library, all databases need to be configured=20
> globally, cgi scripts cannot be run with user permissions and more. For=
=20
> multi-user systems, Apache is superior.
Admittedly its been a long time since I've worked in a highly multi-user=20
environment, but I think these points mostly apply to running external=20
CGI programs, and once you're execing an external progrqam it doesn't=20
matter too much what webserver you're running. For in-process stuff (at=20
least with mod_perl) apache suffers all these same problems, in many=20
cases to a far greater extent.
> Yes, this is one of the solutions. It can technically be done, in multi=
ple=20
> ways, it is even doable, but that is not the point. There is competitio=
n=20
> on port 80, and you need to have a good story to convince your sysadmin=
=20
> (or find concensus in your Open Source project) to replace Apache with=20
> AOLserver on port 80. Again, a social issue.
Again, a marketing problem. It comes down to "no one is using it=20
because no one is using it."
Idle curiosity - I wonder if anyone is running a system with both apache=20
and aolserver listening on port 80 on different ifs/ips. Should be=20
possible and not even difficult, tho probably of limited utility.
-J
| |
| Tom Jackson 2007-08-07, 7:11 pm |
| None of the issues listed really have a solution. The truth is that if yo=
u are=20
doing mass hosting, you should use Apache, the memory footprint is just t=
oo=20
great at some point with AOLserver because you have to load each server a=
t=20
startup. At the very least all code for all virtual servers is in memory,=
at=20
least one copy. Mass hosting of even a hundred domains becomes near=20
impossible. AOLserver cannot be effective in that situation. Apache reall=
y is=20
more like sshd, tcpserver, or any other daemon that is just used to start=
up=20
another process.=20
tom jackson
On Tuesday 07 August 2007 11:37, Dani=C3=ABl Mantione wrote:
> Op Tue, 7 Aug 2007, schreef Jeff Rogers:
e[vbcol=seagreen]
hat[vbcol=seagreen]
>
> If have had very few situations that could rely 100% on AOLserver. Be i=
t
> php scripts (yes, I know you can install php in AOLserver), multi-user
> requirements or political issues.
>
ming[vbcol=seagreen]
here[vbcol=seagreen]
>
> 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).
>
is[vbcol=seagreen]
sy[vbcol=seagreen]
e[vbcol=seagreen]
in[vbcol=seagreen]
>
> Correct, I did this on one of my systems.
>
eads[vbcol=seagreen]
>
> ... 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.
>
t no[vbcol=seagreen]
>
> Yes, this is one of the solutions. It can technically be done, in multi=
ple
> ways, it is even doable, but that is not the point. There is competitio=
n
> 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.
>
e[vbcol=seagreen]
vers[vbcol=seagreen]
>
> 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 install=
ing
> AOLserver on a server rather than Apache becomes feasible for a hosting
> provider.
>
s[vbcol=seagreen]
>
> 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=C3=ABl
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.
| |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| Nathan Folkman 2007-08-07, 7:11 pm |
| 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 <tom@rmadilo.com> 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:
> What
> programming
> there
> is
> his
> easy
> in
> threads
> no
> multiple
> servers
> installing
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <
> listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the
> Subject: field of your email blank.
>
--
Nathan Folkman
nathan.folkman@gmail.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Jeff Rogers 2007-08-07, 7:11 pm |
| 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
| |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| Rusty Brooks 2007-08-07, 7:11 pm |
| I have several interfaces, but one of my interfaces is configured with=20
apache on port 80, and several AOLServer instances on other ports. =20
Apache serves some pages/applications itself and forwards the rest to=20
AOLServer.
Rusty
Dani=EBl Mantione wrote:
> Op Tue, 7 Aug 2007, schreef Jeff Rogers:
>
> =20
he and[vbcol=seagreen]
le and[vbcol=seagreen]
>
> Yes, I have setups like this and is the best solution to this problem.=20
> However, in many situations, multiple ip-addresses are unavailable and=20
> Apache and AOLserver compete for port 80.
>
> Dani=EBl
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <listserv@li=
stserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Sub=
ject: field of your email blank.
| |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| John Buckman 2007-08-07, 7:11 pm |
| >> Idle curiosity - I wonder if anyone is running a system with both
>
> 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
| |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| Daniël Mantione 2007-08-07, 7:11 pm |
| | |
| Nathan Folkman 2007-08-07, 7:11 pm |
| 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 <daniel.mantione@freepascal.org> wrote:
>
>
>
> Op Tue, 7 Aug 2007, schreef Nathan Folkman:
>
> for
>
> Yup, I have installations where AOLserver uses very little memory. Try
> this with Apache
>
> wwwrun 4552 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 <
> listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the
> Subject: field of your email blank.
--
Nathan Folkman
nathan.folkman@gmail.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Jeff Rogers 2007-08-07, 7:11 pm |
| Over in naviserver Vlad (I think) did a bunch of work on vmalloc which=20
tries to actually release the memory back to the system (rather than=20
just the shared pool) on thread exit to keep the process size smaller=20
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 wel=
l to
> help. One example is configuring your threads such that they die and ge=
t
> reaped after a certain number of requests or time. This will cause memo=
ry
> that is currently tied up in the thread's memory pool to be returned ba=
ck to
> the shared memory pool, which can have the net effect of lowering the
> overall process size.
>=20
> - n
>=20
> On 8/7/07, Dani=EBl Mantione <daniel.mantione@freepascal.org> wrote:
ive[vbcol=seagreen]
d[vbcol=seagreen]
>=20
>=20
>=20
>=20
| |
| Michael Andrews 2007-08-07, 7:11 pm |
| I find that the tight coupling of Tcl and AOLserver is really an =20
advantage. You get the Tcl API that comes with the server: thread =20
API, connection API, scheduling API, job control, etc: http://=20
www.aolserver.com/docs/devel/tcl/api/
Tcl is not as widely known as Java/Perl/PHP so most companies are =20
relucant to put money into a platform they "think" will be difficult =20
to support later. I usually show the cost/bennifit of AOLserver Vs. =20
Java: The number of hosts, the development timeline, and ease of =20
deplyment are among some of the things I cite. Of course, there are =20
always counter points, but in general - I believe that AOLserver/Tcl =20
is really the best bang for the buck. It is all about showing the =20
value and cost/benefits. In the end that is the best argument for any =20
technology choice.
On Aug 7, 2007, at 5:12 PM, Dani=EBl Mantione wrote:
>
>
> Op Tue, 7 Aug 2007, schreef Jeff Rogers:
>
>
>
>
> Many people here can give you a long list why AOLserver is the best =20
> 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 =20
> 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=EBl
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to =20
> <listserv@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the =20
> Subject: field of your email blank.
| |
| Jeff Rogers 2007-08-07, 7:11 pm |
| Dani=EBl Mantione wrote:
> I'm not to happy to call it a marketing issue, because this suggests th=
at=20
> if you would have a big enough advertising campain, you can make AOLser=
ver=20
> win from Apache. This is not the case.
Software lock-in is very difficult to undo (ever try to get someone to=20
change their preferred text editor? mail tool? word processor?=20
webserver ... ) But it *can* be done. Either through convincing them=20
of the benefits (slow and painful), forcing them (not always possible),=20
or providing something that they cannot get elsewhere (e.g., a new=20
framework, access to the company email, or whatever).
I don't really mean marketing as in a public relations campaign=20
(although that certainly wouldn't hurt), I mean it more as education and=20
changing the public perception. How to do that? If I knew I'd probably=20
be rich (or a politician).
> It is the way you need to work with AOLserver that causes these problem=
s.=20
> Not because AOLserver cannot do something (on the contrary, it is one o=
f=20
> the most capable web servers), but you run into social/political issues=
,=20
> like you needing port 80, have a user who has a mysql application in hi=
s=20
> 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=20
particular political/social situation. AOLserver can do nearly=20
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=20
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=20
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
| |
| Dossy Shiobara 2007-08-08, 1:11 am |
| On 2007.08.07, Dani?l Mantione <daniel.mantione@FREEPASCAL.ORG> 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 | dossy@panoptic.com | 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)
| |
| Dossy Shiobara 2007-08-08, 1:11 am |
| On 2007.08.07, Jeff Rogers <dvrsn@DIPHI.COM> 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 | dossy@panoptic.com | 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)
| |
| Dossy Shiobara 2007-08-08, 1:11 am |
| On 2007.08.07, John Buckman <john@MAGNATUNE.COM> 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 | dossy@panoptic.com | 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)
| |
| Dossy Shiobara 2007-08-08, 1:11 am |
| On 2007.08.07, Jeff Rogers <dvrsn@DIPHI.COM> 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 | dossy@panoptic.com | 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)
| |
| Dossy Shiobara 2007-08-08, 1:11 am |
| On 2007.08.07, Jeff Rogers <dvrsn@DIPHI.COM> 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/...r-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/...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 | dossy@panoptic.com | 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)
| |
| Tom Jackson 2007-08-08, 1:11 am |
| 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
| |
| Bas Scheffers 2007-08-08, 1:11 am |
| On 7 Aug 2007, at 23:07, Dossy Shiobara wrote:
> 1) Java script: 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.
| |
| Tom Jackson 2007-08-08, 1:11 am |
| 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
| |
| Bas Scheffers 2007-08-08, 7:11 am |
| 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.
| |
| John Buckman 2007-08-08, 7:11 am |
| > On 2007.08.07, John Buckman <john@MAGNATUNE.COM> wrote:
>
> 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 <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Daniël Mantione 2007-08-08, 7:11 am |
| | |
| Jeff Rogers 2007-08-08, 7:11 am |
| Bas Scheffers wrote:
> On 8 Aug 2007, at 14:08, Tom Jackson wrote:
[vbcol=seagreen]
> 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.
How does it compare to the tools in nsdci? Both seem to be roughly the
same thing - a hashtable accessible over the network. (I've used neither)
-J
| |
| Jeff R 2007-08-08, 7:11 am |
| 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
| |
| 'Jesus' Jeff Rogers 2007-08-08, 7:11 am |
| Dani=EBl Mantione wrote:
> Ok, practical example:
>=20
> We have a server, two users want to run OpenACS, and 20 users simply=20
> wants to code PHP/MySQL. Proposal to the system administrator: Put poun=
d=20
> on Port 80 and have requests for the two OpenACS users redirected to th=
eir=20
> own AOLserver process.
>=20
> Now, everyone on the server will see all requests coming from localhost=
..=20
> 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=20
that it is a proxied request. In certain environments (firewalled=20
corporate paranoia) you can't avoid everything being proxied and must=20
deal with this. And more to the point, there are simple ways (about 4=20
lines of code in a PerlFixupHandler) to recover the proxied connection=20
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=20
saps who subject themselves to php will be happy and the OACS users can=20
have a real system to work with.
Obnoxious alternate answer 2: tell the php users, "sorry, there's people=20
doing real work on this system."
Bottom line is, there's no reason why they can't coexist peacefully.
-J
| |
| Guan Yang 2007-08-08, 7:11 am |
| 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
| |
| Jeff Rogers 2007-08-08, 7:11 am |
| Dossy Shiobara wrote:
> http://panoptic.com/wiki/aolserver/...r-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
| |
| John Buckman 2007-08-08, 7:11 am |
| > 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
| |
| Daniël Mantione 2007-08-08, 7:11 am |
| | |
| Jeff Rogers 2007-08-08, 7:11 am |
| Dani=EBl Mantione wrote:
> Again, a practical situation: How many php packages support such header=
s?=20
> (Even OpenACS doesn't support them, so you would have to fix OpenACS to=
o.)=20
> Can you (socially) convince those users to rewrite the php apps for you=
to=20
> use your OpenACS?
As a practical solution, if you needed to do it transparently you'd=20
install a trivial C module to patch the request_rec or Conn and change=20
the peer address to the value given in the proxy header. php or OACS=20
wouldn't know the difference. In apache if you have mod_perl installed=20
this is very easy (the C module boilerplace would be 5x the size of the=20
actual code for the module). As for AS, I believe this was done in one=20
or more of the old proxy modules; I don't know offhand exactly what it=20
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=20
a whole lot of technical wizardry to overcome the inertia of "I don't=20
know that system."
-J
| |
| Gustaf Neumann 2007-08-08, 7:11 am |
| Dani=EBl Mantione schrieb:
> Again, a practical situation: How many php packages support such header=
s?=20
> (Even OpenACS doesn't support them, so you would have to fix OpenACS to=
o.)=20
> =20
i am not sure, where this discussion is supposed to lead to. A couple of=20
years ago, i argued
here on the list to have support on the aolserver side for exactly this=20
task. The
argument was, it is simple enough to do it on the application layer, no=20
need for direct
support in aolserver. Up to a certain point, this was true, i ended up=20
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
}=20
}
two points:=20
a) i still believe, that a aolserver newbies (if this species exists) wil=
l
have troubles to handle this case: they rather look for a configure=20
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=20
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=20
> use your OpenACS?
> =20
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
| |
| Daniël Mantione 2007-08-08, 7:11 am |
| | |
| Thorpe Mayes 2007-08-08, 7:11 am |
| >
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.
The format does not matter. It can be html, pdf, or paper.
Only someone who really knows AOLServer can create this document. It
will be a chore, but is must be done. I could not begin to write this
document. However, I will be happy to help edit it.
A document like this will not ensure AOLServer's success. But I can
promise you that without a document like this, AOLServer is doomed.
Good luck.
Thorpe
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Mark Aufflick 2007-08-09, 1:11 am |
| On 8/7/07, Dossy Shiobara <dossy@panoptic.com> wrote:
> 1) Java script: 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.
| |
| Titi Alailima 2007-08-09, 1:11 pm |
| 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:AOLSERVER@LISTSERV.AOL.COM] 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 <dossy@panoptic.com> wrote:
> been
> started
> is
> you
> build
> 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.
| |
| Guan Yang 2007-08-09, 1:11 pm |
| Titi Alailima wrote:
> 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.
You may want to take a look at Helma, which is an existing
JavaScript-based application server and framework (written in Java). It
should give you an idea of what server-side JavaScript *could* look like.
/Guan
| |
| Dossy Shiobara 2007-08-09, 1:11 pm |
| On 2007.08.09, Jim Davidson <jgdavidson@MAC.COM> 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
--
Dossy Shiobara | dossy@panoptic.com | 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)
| |
| Jim Davidson 2007-08-09, 1:11 pm |
|
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 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.
>
> The format does not matter. It can be html, pdf, or paper.
>
> Only someone who really knows AOLServer can create this document.
> It will be a chore, but is must be done. I could not begin to write
> this document. However, I will be happy to help edit it.
>
> A document like this will not ensure AOLServer's success. But I can
> promise you that without a document like this, AOLServer is doomed.
>
> Good luck.
>
> Thorpe
>
>
>
> --
> AOLserver - http://www.aolserver.com/
>
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> 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 <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
| |
| Jeff Rogers 2007-08-09, 1:11 pm |
| Dossy Shiobara wrote:
> On 2007.08.09, Jim Davidson <jgdavidson@MAC.COM> wrote:
>
> 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
| |
| Tom Jackson 2007-08-09, 1:11 pm |
| 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
| |
| Daniël Mantione 2007-08-09, 7:11 pm |
| | |
| Tom Jackson 2007-08-09, 7:11 pm |
| On Thursday 09 August 2007 11:28, Dani=C3=ABl 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 hav=
e a=20
module for Apache. It would save you a few buck on hosting. How much=20
community effort should go into saving a few bucks? I am not saying that =
if=20
such a thing appeared all by itself more people wouldn't use it. Could it=
not=20
be just as easy to convince your hoster to proxy to a user space AOLserve=
r?
After all, once you have AOLserver installed, you might want to use a=20
database, or install other modules or change the configuration. Do you no=
w=20
need to bug your hoster every time you want to change a configuration?=20
This model seems to require that a new user convince themselves to use=20
AOLserver, then convince their hoster to handle the installation. And the=
=20
hoster isn't getting paid very much, if anything, for the trouble.=20
Somehow I think that years of effort could go into transforming AOLserver=
into=20
an Apache clone, but it still isn't Apache. Nobody is dissatisfied with=20
Apache for the problem space AOLserver would need to move into. =20
AOLserver has multi-user capabilities on a system. Each user can run as m=
any=20
AOLservers as they want. What they can't do is all use the same ip:port. =
Just=20
get another ip and problem solved. Also, for static content, AOLserver ca=
n=20
easliy work as a mass hosting solution. The main issue is you can't give =
a=20
bunch of independent users a chance to execute Tcl commands, maybe you co=
uld=20
delete some of the Tcl API and make it safe, that would be another=20
possibility. Someone suggested multi-user really means multi-process. So =
this=20
might be a question of operating system support. Is it possible?=20
tom jackson
| |
| Tom Jackson 2007-08-09, 7:11 pm |
| Nobody can argue that better isn't better. There are certain things which=
seem=20
difficult in AOLserver, maybe more difficult than they should be, but may=
be=20
not.
One is writing a new C module. I've done some where I use a shared .so mo=
dule=20
for the interesting library code, and I think I have used a static .la (o=
r=20
whatever it is) file. The difficulty seems to be in using the Tcl C API =
to=20
make a place to store application data, like handle pointers, etc. Maybe =
this=20
is just as hard in Apache? Being able to more easily reuse existing C=20
libraries would provide a long term benefit. Maybe this would be easier w=
ith=20
ns_proxy and a single threaded/isolated process.=20
Another issue related to C modules is that you can load libnsd into a tcl=
=20
interp, or just run nstclsh. But you can't load modules, or at least I do=
n't=20
know how to do it. It would probably take a lot of work to get nsd to run=
as=20
a server inside a tclsh, but what about being able to run nsd with no=20
servers, maybe with Tk as the face of the process, maybe a new main funct=
ion=20
called nstk. Seems complicated to do, maybe just a module needs to be=20
written that could startup a Tk thread? Being able to use the database an=
d=20
scheduling APIs in a desktop application would be an intesting new area f=
or=20
the AOLserver codebase. Maybe there is something already in this area wit=
h=20
Tcl/Postgres/Oracle/etc?
tom jackson
On Thursday 09 August 2007 11:28, Dani=C3=ABl 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 | | |