Dossy Shiobara schrieb:
On 2007.09.27, Jeff Rogers <[EMAIL PROTECTED]> wrote:
[...] It seems at first glance that it would make more sense to hand
the task of writing to the connection back to the driver thread once
the connection thread is done with it, [...]
I don't know if the chang
On Sep 28, 2007, at 8:43 AM, John Buckman wrote:
My solution to that problem was simply caching in the filesystem
and serving static files. The way this works in a multi-server
environment is that the custom 404 handler figures out the request
was for "/photo/123/axbcgsfdt.jpg" and just grab
I see your point, and I might change it at some point, but it's sort of
"good enough" as it is... I'm replacing stuff that takes, say, 10s with
something that I can fetch, say, 1000/s. It doesn't matter too much if
I can do it 1000, 2000, or 5000/s, as lot as it's not 1/s.
Rusty
Dossy Shioba
On 28/09/2007, at 9:28 AM, Dossy Shiobara wrote:
Yes! Finally, someone else who uses the 404-handler-as-request-
processor
pattern! Indeed, you can't beat static file serving performance.
And,
My first inspiration for this came way back in the last century, from
working with Vignette Story
On 2007.09.27, Rusty Brooks <[EMAIL PROTECTED]> wrote:
> Yeah, I do this too. To "dirty" the cache you can just delete the
> file. I do regular rounds to delete old files.
>
> I don't use the 404 though, that's a neat idea. Instead I register a
> proc that ns_returnfiles the cache file if it
On 2007.09.28, Bas Scheffers <[EMAIL PROTECTED]> wrote:
> My solution to that problem was simply caching in the filesystem and
> serving static files. The way this works in a multi-server
> environment is that the custom 404 handler figures out the request
> was for "/photo/123/axbcgsfdt.jpg"
On 2007.09.28, Bas Scheffers <[EMAIL PROTECTED]> wrote:
> I would suspect Linux being faster on a box like this than OS X (BSD)
> because of better threading support. Or am I wrong in that assumption?
I'm only guessing, but I doubt there would be a significant performance
difference between OS X
Yeah, I do this too. To "dirty" the cache you can just delete the
file. I do regular rounds to delete old files.
I don't use the 404 though, that's a neat idea. Instead I register a
proc that ns_returnfiles the cache file if it exists, otherwise it makes
it and then returns it.
Bas Scheff
On 28/09/2007, at 5:04 AM, John Buckman wrote:
I've been looking at C-caching of Tcl dynamic content, with "dirty
cache" support. For example, replacing the Tcl code that returns a
user's uploaded photo with C code.
I wrote C code to do this, and got 14k/second vs 240/s for the same
tcl f
On 28/09/2007, at 3:38 AM, Dossy Shiobara wrote:
I bet with just a few minutes of tweaking and tuning, we can get
between
4k-8k simple dynamic req/sec out of your hardware.
Hear, hear. I just blasted my brand-spanking-new Quad 2.6 Mac Pro
using ab. I was testing my ns_session, so it was doing
On 9/27/07, John Buckman <[EMAIL PROTECTED]> wrote:
> When comparing lighthttpd vs aolserver, notice that aolserver only
> does worse than lighthttpd for large files, and on the same file
> system/hardware. Thus, the difference in benchmarks is not likely to
> be the access logs or disk.
>
> Lighth
Hmm--I'm not sure what you're thinking of or referring to, but the
common "optimization" is to use sendfile(2), which seems to be
alive and well in the 2.6 tree.
Whoops, you're right, I just remembered a sysadmin email about
sendfile not existing on the kernel we're using. Hmm...
Sendfile r
On Thursday 27 September 2007 11:08, Dossy Shiobara wrote:
> It might be possible to push static file processing further up the chain
> into the DriverThread and get better performance on larger static
> files--or, have one dedicated I/O thread separate from the main driver
> thread to handle async
On 2007.09.27, Jeff Rogers <[EMAIL PROTECTED]> wrote:
> [...] It seems at first glance that it would make more sense to hand
> the task of writing to the connection back to the driver thread once
> the connection thread is done with it, [...]
>
> Since this is such an obvious change, would I be co
On Thursday 27 September 2007 09:55, John Buckman wrote:
> When comparing lighthttpd vs aolserver, notice that aolserver only
> does worse than lighthttpd for large files, and on the same file
> system/hardware. Thus, the difference in benchmarks is not likely to
> be the access logs or disk.
Yeah
On 2007.09.27, John Buckman <[EMAIL PROTECTED]> wrote:
> Lighthttpd is *not* using the system call to send a file to a socket
> (I forget the name) as this call was taken out of the Linux kernel, I
> believe with 2.4. I remember reading a note about this from Linus,
> that the performance fo
Tom Jackson wrote:
I was looking at lighttpd performance
(at http://trac.lighttpd.net/trac/wiki/Docs%3APerformance )
Considering how well AOLserver stands up to lighttpd, my question was why does
lighttpd do better?
I was wondering if it had something to do with how aolserver does its
write
On 2007.09.27, Tom Jackson <[EMAIL PROTECTED]> wrote:
> Another reason might be that lighttpd doesn't write an access.log by
> default. I wonder if you can turn this off in AOLserver?
Yes, you can. If you don't load the nslog module, you turn off access
logging.
-- Dossy
--
Dossy Shiobara
I was looking at lighttpd performance
(at http://trac.lighttpd.net/trac/wiki/Docs%3APerformance )
Considering how well AOLserver stands up to lighttpd, my question was why does
lighttpd do better?
For sending small files AOLserver is slightly better, but then performance
goes down.
One reaso
www64:/b# ab -c 5 -n 5 http://images.bookmooch.com/x.txt
Since your machine is a 2-CPU 8-core box, could you try runs with -c 8
and -c 16? It may have no effect, but it'd be nice to know that for
sure.
I get more-or-less the same numbers at -c 8, -c 16 and -c 32, varying
about 100 reque
On 2007.09.25, John Buckman <[EMAIL PROTECTED]> wrote:
> I did some benchmarks of aolserver vs lighthttpd on plain files of
> various sizes, on my 8cpu 64 bit server.
Thanks! This is all fantastic information to have!
> www64:/b# ab -c 5 -n 5 http://images.bookmooch.com/x.txt
Since your m
I'm not sure if my post is off-topic, but when I did compile
Aolserver in my x86-64 machine I had problems with TCL, tDOM (not
Aolserver).
You can see my problem in: http://openacs.org/forums/message-view?
message_id=369867
It was a problem I had installing Aolserver. I think it doesn't
matt
Dossy,
You are right, previously I posted my info because I'm running on 64-bit AMD
and AOLserver was running without problems. I have Tcl 8.4.14.
I wasn't sure what the command was to detect 64-bit, but I just found
that 'file exename' works:
$ file nsd
nsd: ELF 64-bit LSB executable, AMD x86
Hi!
I'm not sure if my post is off-topic, but when I did compile Aolserver
in my x86-64 machine I had problems with TCL, tDOM (not Aolserver).
You can see my problem in:
http://openacs.org/forums/message-view?message_id=369867
It was a problem I had installing Aolserver. I think it doesn't
On 2007.09.24, Tom Jackson <[EMAIL PROTECTED]> wrote:
> I know I didn't make this change, but my include/ns.mak file has this:
...
> LDLIB = gcc -pipe -shared -nostartfiles
This is likely a Tcl version related issue--older versions of Tcl (i.e.,
tclConfig.sh) had the LDLIB you see above,
I know I didn't make this change, but my include/ns.mak file has this:
# $Header: /cvsroot/aolserver/aolserver/include/ns.mak.in,v 1.5 2006/06/27
17:00:55 jgdavidson Exp $
.
LDLIB = gcc -pipe -shared -nostartfiles
tom jackson
On Sunday 23 September 2007 15:40, Dossy Shiobara wrot
On Saturday 11 August 2007 05:34, Andrew Piskorski wrote:
> On Thu, Aug 09, 2007 at 01:04:06PM -0700, Tom Jackson wrote:
> > Subject: Re: [AOLSERVER] aolserver focus
> >
> > There are certain things which seem difficult in AOLserver, maybe
> > more difficult than th
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
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
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 cho
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 re
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 binar
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
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 r
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
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
>
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 insufficien
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 fi
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, Thorp
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 underst
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 AOLserv
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 gen
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
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
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
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 AOLse
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
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
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 fo
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 tclm
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,
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 neces
Bas Scheffers wrote:
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
AOL
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 c
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
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. T
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, ho
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,
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 differen
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 politic
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 w
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. AO
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 Ap
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
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 the
I find that the tight coupling of Tcl and AOLserver is really an
advantage. You get the Tcl API that comes with the server: thread
API, connection API, scheduling API, job control, etc: http://
www.aolserver.com/docs/devel/tcl/api/
Tcl is not as widely known as Java/Perl/PHP so most compani
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 Folkm
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
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, wha
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 c
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 ma
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:
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
Op Tue, 7 Aug 2007, schreef Jeff Rogers:
> 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
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 vi
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
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 b
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
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
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 p
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 ocnsi
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
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 deve
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 t
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
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 AOLS
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:
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
ECTED] 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" di
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 actua
John Buckman wrote:
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 installe
> 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
> y
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 ne
Hi,
> This used to be a problem in older AOLserver 4.0, where the IP address
> you're using was missing reverse DNS ... but yours is failing in
> NsInitConf() ... are you sure you're loading the correct libnsd.so?
I'd
> check your LD_LIBRARY_PATH and be extra-careful.
I checked everything and did
You'll probably also want to make sure you're building Tcl such that it
isn't using the "Zippy" threaded allocator code. Not sure if the Tcl folks
ever fixed this, but it used to be that there was no easy way to build
threaded Tcl without getting the "Zippy" allocator built as well. Using the
Tcl
On 2007.05.24, Agnieszka Kuka?owicz <[EMAIL PROTECTED]> wrote:
> Ns_TlsGet: invalid key: 0: should be between 1 and 100
This used to be a problem in older AOLserver 4.0, where the IP address
you're using was missing reverse DNS ... but yours is failing in
NsInitConf() ... are you sure you're loadi
On 2007.05.21, Tom Jackson <[EMAIL PROTECTED]> wrote:
> I don't care too much which db is included, and these appear to be the ones
> you wrote drivers for, no?
Coincidentally, yes. I chose to include components that I could
personally support 100% by myself. The last thing I want is for a
com
Dossy,
I don't care too much which db is included, and these appear to be the ones
you wrote drivers for, no?
But what was the decision for 4.0.10 as opposed to 4.5? I don't think it
matters to anything I do, but it would be interesting to hear.
Thanks for the effort, hopefully some new user
On 2007.05.21, Mark Aufflick <[EMAIL PROTECTED]> wrote:
> You don't want to bundle the world's best web opensource server with
> the worlds not-best (and not very open source) dbms!
You're absolutely right! That's why I didn't include PostgreSQL. :-P
(Sometimes, quoting out of context can be gr
Would it make sense to also include postgres support by default? You
don't want to bundle the world's best web opensource server with the
worlds not-best (and not very open source) dbms!
If I get a chance this week I'll download the image and have a play.
On 5/20/07, Francesco P. Lovergine <[EMA
201 - 300 of 1254 matches
Mail list logo
