[AOLSERVER] is it necessary
nitin chandra
Is it necessary to install OpenACS along with AoLserver?
Nitin
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
David Siktberg
started by using ACS (OpenACS's predecessor) as a foundation and a
jumping-off point to learn from - we picked only the parts we needed from
ACS, primarily infrastructure management (security, user registrations,
shared functions, etc.) and added much more of our own using tcl scripts.
Only about 5% of the current site came from ACS.
Dave Siktberg
Webility Corporation
Don Baccus
> Hi Everyone,
>
> Is it necessary to install OpenACS along with AoLserver?
No, OpenACS is just a web toolkit that uses AOLserver, just as Django
uses Apache.
----
Don Baccus
http://donb.photo.net
http://birdnotes.net
http://openacs.org
nitin chandra
Tom Jackson
AOLserver is independent of OpenACS.
But you might join the OpenACS community, and/or use their resources
(openacs.org), they discuss a wider range of things than we do here.
tom jackson
nitin chandra
But somehow i am still waiting for support / guidance for installation
of my AoLserver
In that regard I have already requested the list .... twice.... still
no response.
Sub : AoLserver 4.5.1 install issue
Still waiting ...
Hope someone will .... :)
Nitin
Dave Bauer
> Hi Everyone,
>
> Is it necessary to install OpenACS along with AoLserver?
No. OpenACS is just one application built on the AOLserver platform.
Dave
>
> Nitin
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
>
--
Dave Bauer
da...@solutiongrove.com
http://www.solutiongrove.com
nitin chandra
After a lot of attempts i was successful in installing the AoLserver
but not PyWX or for that matter any thing which will integrate with
Python.
Support regarding PyWX on AoL is non-existent, and key people have
stopped working / supporting this combo around 8yrs back (at least one
person said so).
AoL is a great product ... but the future ...as far as my personnel
view is ..... not very bright.
I am sure when .... "when" .... there is a dedicated team ... it will
make a refreshing difference in the Webserver landscape.
Above are my personnel views and are not intended to start any flame wars...
Thank you
Nitin
Tom Jackson
with AOLserver.
You really have to understand that AOLserver is a Tcl application. It
isn't a matter of supporting a new language, like Apache. But please
realize that Apache doesn't support any language, it simply provides
an all intrusive, and relatively horrible API to the server. You want
to use Apache? Adopt their horrible API.
People who use AOLserver tend to realize this problem and avoid it by
instinct. The truth is that there are many applications which seem to
work perfectly well during development...when only one person is
actually using the system...but start to fail when exposed to the real
world. AOLserver tends to avoid this problem and for some reason
outperforms all specialized servers with the exception of OS based
transfers of very large files (but AOLserver still retains the ability
to record errors during such large file transfers, while offloaded
responses lose this ability).
The biggest long term threat to AOLserver is potential changes to the
C and Tcl level APIs coming out of the Tcl community.
First remember, if you can, that Tcl owes its
multi-threading/thread-safe capability to the developers of AOLserver.
But the current leaders of the Tcl community seem mostly not
interested in acknowledging this history...even though the latest Tcl
versions include threads as a default. The community leaders seem
convinced that an event model, alone, works best. Unfortunately their
current API lacks enough depth to really support a robust event driven
application.
The main defect in the Tcl only/event only model is the lack of a
controller that sits above or around the execution environment.
AOLserver solves this in a more limited and targeted way than a JVM or
C# environment. Yet we have seen Java move closer to the AOLserver
architecture, but they still have problems (it is still Java or C#).
The only really positive thing I can say about python is that it is
relatively easy to translate into Tcl.
But if you want to do client/server with a major in HTTP-like
messaging, AOLserver is still way ahead of any competition.
tom jackson
Jeff Rogers
> Thank you Everyone,
>
> After a lot of attempts i was successful in installing the AoLserver
> but not PyWX or for that matter any thing which will integrate with
> Python.
>
> Support regarding PyWX on AoL is non-existent, and key people have
> stopped working / supporting this combo around 8yrs back (at least one
> person said so).
The C-python implementation has a misfeature known as the global
interpreter lock (GIL) that presents scalability problems in a threaded
environment like AOLserver. I suspect whoever was working on the python
integration ran headlong into this, got frustrated, and gave it up.
AOLserver is bound to tcl at a pretty deep level, and it does so very
well. While there is some support for other languages (php, perl,
python, ML maybe?) it will never be as good as the tcl binding.
-J
Bas Scheffers
> The C-python implementation has a misfeature known as the global
> interpreter lock (GIL) that presents scalability problems in a threaded
Tcl seems to be the only language that is thread safe and can be embedded in the way it is in AOLserver.
And like others have said: AOLserver actually uses a lot of the Tcl API. Most Tcl commands have a C equivalent that can be used outside an interpreter. With the few C modules I have made good use of this, using the String functions and not relying on things like glibc, for instance. (even glibc itself has many threading issues; I tried the str functions and in a high-load concurrent environment, they blew up and segfaulted.)
Bas.
Andrew Piskorski
> The C-python implementation has a misfeature known as the global
> interpreter lock (GIL) that presents scalability problems in a threaded
Right.
> AOLserver is bound to tcl at a pretty deep level, and it does so very
> well. While there is some support for other languages (php, perl,
> python, ML maybe?) it will never be as good as the tcl binding.
I'm not so sure your second statement there is true. What I think IS
true, is that yes AOLserver is bound to Tcl at a pretty deep level, so
you certainly can't take Tcl out of AOLserver - nor should you want
to. Tcl is pretty much in there to stay.
However, that doesn't necessarily mean that you can't make some other
language just as well supported for AOLserver application level
development as Tcl is, if you wanted to. As far as I know there's
nothing in AOLserver's design that really prevents that, it's just a
Simple Matter of Programming.
Good choices would be any language implementation that's reentrant and
intended for easy embedding in C code. Obvious candidates are
JavaScript, Lua, and probably a couple of the dozens of Scheme
implementations out there.
With various levels of completeness, people have tried:
- Standard ML, Objective CAML, PHP. (I think all used in Production
for limited or specialized purposes, e.g. to run canned PHP webmail
apps.)
- Python. (Sounded like a fair bit of development, but no live use AFAIK.)
- Scheme, Ruby, Perl, etc. (Early development only AFAIK, never
finished and haven't seen any real use).
See also: http://panoptic.com/wiki/aolserver/Languages
In fact, although I am NOT particularly familiar with AOLserver's
internals (so I certainly could be mistaken), I'd bet that adding good
AOLserver support for some other scripting language would be easier
than in most other C-coded application servers which DON'T already
have tight and reasonably clean scripting language integration.
The Tcl support should have already laid most of the groundwork; you
shouldn't need to invent APIs and interfaces, just provide your new
Language X equivalents for the Tcl stuff that's already there. The
only tricky parts might be language implementation specific magic like
the Tcl interpretor initialization.
I think a deeper question is, are you sure you want to do that anyway?
People who see AOLserver's usefullness usually just decide to use the
languages it comes with built in, Tcl and C. But you could instead
try something completely different from the scripting-language-and-C
AOLserver-esque paradigm, like Erlang. Or if you are a real hard-core
lover of language X, perhaps you want to build your own application
server yourself; I suspect that's what most language partisans or
enthusiasts do.
--
Andrew Piskorski <a...@piskorski.com>
http://www.piskorski.com/
Andrew Piskorski
> Subject: Re: [AOLSERVER] is it necessary
> Tcl seems to be the only language that is thread safe and can be
> embedded in the way it is in AOLserver.
Lua should definitely work. Indeed, Lua is supposed to be even easier
to embed than Tcl. It basically came to exist because back in 1993,
its creators wanted a dynamically typed language that was small,
simple, cross platform, and readily embeddable, but they didn't care
for Tcl.
There are also some nice-sounding thread-safe Javascript
implementations out there, which should be embeddable. Dossy was
enthusiastic about those a while back, and started on "nsjsapi".
Lua also has cool stuff like LuaJIT, and it should be straightforward
to build Tcl-like "apartment model" (aka, lightweight process)
threading and inter-thread communications. Hm, I remember talking
about this before; yeah back in April 2008:
http://groups.google.com/group/aolserver/msg/13fec53483ddfb0c
Check out the rest of that old thread too; a bunch of people had
useful stuff to say about adding new programming languages to
AOLserver, some of its history, and related matters.
--
Andrew Piskorski <a...@piskorski.com>
http://www.piskorski.com/
Bernd Eidenschink
> model where they keep one interpreter per process (like PHP) or party like
> it's 1993 in a FastCGI environment like Ruby (on Rails) does. Yuk.
Don't name the FastCGI-party-people, they are mean!
Albeit there applications have momentum, FAQ's, HowTos, packages in nearly
every linux distribution, books to buy, thousands of developers; albeit they
power all the world-famous well-known apps everyone uses, they use this lame
technology. Even worse, if there apps stall, they place nginx or lighttpd with
memcached in front of it and survice slashdot, just mad!
Hm.
Even using and relying on several AOL- and Naviservers for years now I cannot
get used to the technical superiority discussions...
"So what? TCL is thread safe (tm)!"
Bernd.
Tom Jackson
offload of static content which blows doors.
On Tue, Oct 27, 2009 at 2:25 AM, Bernd Eidenschink <eiden...@web.de> wrote:
> Even using and relying on several AOL- and Naviservers for years now I cannot
> get used to the technical superiority discussions...
I thought it was just easier to use...I'm lazy as hell.
Also, the "other languages" which AOLserver already supports: database
languages. And that provides, for me, the prefect model for supporting
high level technology of every variety. There is also the more generic
nsproxy module, although I'm not really sure if you can run anything
in the proxy, maybe it is just a place to run tcl code which isn't
thread-safe...still is probably the best place to demo additional
programming languages running alongside a tcl interp.
tom jackson
Bas Scheffers
> Even using and relying on several AOL- and Naviservers for years now I cannot
> get used to the technical superiority discussions...
In short: AOLserver is better for the environment. If you run anything other than AOLserver, YOU HATE THE EARTH! It's why Greenpeace uses OpenACS!
Seriously though, you can make a succesful service on any platform. That doesn't mean the Twitter boys couldn't have saved themselves a whole lot of sleepness nights by going with a better architecture initially, instead of the hard to scale flavor of the month.
One of the most important reasons those platforms are more popular is because they all run in Apache and install with one tick of a box or "apt-get/yum" command, as well as working in large virtual hosting environment. (i.e.: cheap web hosts)
Moving AOLserver to run inside Apache as a module would be a great step to making it more accesible and popular.
Bas.
Dossy Shiobara
> Moving AOLserver to run inside Apache as a module would be a great step to making it more accesible and popular.
This is the reason why I'd like to implement a module for AOLserver that
would enable it to run as a FastCGI application under Apache and/or
Lighttpd or any other webserver that speaks FastCGI.
--
Dossy Shiobara | do...@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
blend aolserver with other app servers (lamp, ruby etc) now without
actual code changes ? I'm wondering if folks have done that
successfully
Jim
Sent from my iPhone
Bas Scheffers
AOLserver. This is mostly where we have a scarcity of IPs.
But that still means you have to jump through hoops to install it,
learn how to run it in production, etc.
I'd love a being able to just say "apt-get install apache2-aolserver
apache2-aolserver-postgresql".
Then have a config section in the virtual server where you define db
pools, the location of your tcl lib directories, etc. This could be
overridden by .htaccess files so that you may download a complete
package (say a blog, like WordPress), dump it in the page root and
the .htaccess would say "./tcllib" is just that and you could define
pools (written to .htaccess) in "config.adp".
A completely independent interpreter pool would be maintained for each
virtual server. It could even be the only "scripting module" to be
able to run in a fully threaded Apache. (but still needs to run in a
forking environment so it can play nice with PHP)
No, this won't be as great and efficient as AOLserver is, but it will
be a whole lot easier for people to use and sell to fellow staff,
management, clients, etc.
Just my thoughts on the subject! (And I do realise this is a whole lot
of work!)
Bas.
Dave Bauer
> I do this for a couple of sites, Apache's mod_proxy forwards stuff to
> AOLserver. This is mostly where we have a scarcity of IPs.
>
> But that still means you have to jump through hoops to install it, learn how
> to run it in production, etc.
>
> I'd love a being able to just say "apt-get install apache2-aolserver
> apache2-aolserver-postgresql".
Of course you can say apt-get install aolserver4 already.
Dave
--
Tom Jackson
> I do this for a couple of sites, Apache's mod_proxy forwards stuff to
> AOLserver. This is mostly where we have a scarcity of IPs.
>
> But that still means you have to jump through hoops to install it, learn how
> to run it in production, etc.
>
It is strange that the most valid reason to use Apache is a lack of IP
addresses. But it's true.
> I'd love a being able to just say "apt-get install apache2-aolserver
> apache2-aolserver-postgresql".
As soon as apt-get blah-blah-blah starts installing software where I
want it, with the options I want, I also would love it. But if I
install an AOLserver for a client, they might want to keep their
version for a few years, the next client might want the current
version and a new postgresql. The apt-get stuff works exactly once per
machine and it still doesn't give much flexibility. Eventually you
have to learn how to do custom installs.
I like the idea of a forward (caching) proxy, it fits in well with the
filter type architecture in AOLserver.
tom jackson
Bas Scheffers
> Of course you can say apt-get install aolserver4 already.
The vast majority of people that *use* LAMP and not developers, nor have any heroic sysadmin skills. They just download WordPress or Drupal or Gallery, dump it into their page root and away they go. They may tweak a few templates with PHP code in them, but that's it.
That's the kind of simplicity AOLserver needs to grow. We live in an Apache world; if you can't beat them, join them...
Bas.
Jim Davidson
isn't generally) but more naturally blending the AOLserver API's and
Tcl stuff into Apache seems smart in the year 2009.
Question: Does anyone (really) care about Win32 now? Poking at the
code today, I'm thinking config/build/install of a library that could
be used by a mod_aolserver would be cleaner without that cruft.
Disclosure: I wrote most of that Win32 wrapper/build muck. It's
existence now offends me :) Thinking back, my time and life energy
would have been better spent drinking heavily than trying to navigate
some silly intersection of Unix (which is mostly elegant) and Windows
(which is, well, not so elegant).
-Jim
Rusty Brooks
their in-house IT staff is windows only.
A cygwin port would probably be good enough though, and maybe that's
easier than a full-blown win32 native port?
Rusty
Bas Scheffers
> I like this approach, doesn't need to be perfect performance (PHP
> isn't generally) but more naturally blending the AOLserver API's and
> Tcl stuff into Apache seems smart in the year 2009.
Didn't AD do a module years ago? I don't think it was integrated beyond forwarding request; still requiring full, standard AOLserver configuration. Eve A. even keeps a copy around: http://www.eveandersson.com/arsdigita/acs-repository/mod_aolserver-1.1
> Question: Does anyone (really) care about Win32 now? Poking at the
Well, if we do the above, people might care more than ever; being able to develop on their Windows box (just like they do using WAMP) and deploy on Linux.
Bas.
Andrew Piskorski
> Question: Does anyone (really) care about Win32 now?
The cross-platformness of Tcl and AOLserver have definitely been
useful to me in the past. In fact I'm still running AOLserver on
Windows today, but essentially as the platform for a custom
network-aware application, not a web server at all. If I had to, I
could probably code my own minimal replacements for the AOLserver
services I actually used in tclsh, particularly since Zoran's Tcl
Thread Extension already ported (and then improved) the nsv_* APIs,
etc.
--
Andrew Piskorski <a...@piskorski.com>
http://www.piskorski.com/
Maurizio Martignano
have you ever looked at the Win32-OpenACS distribution?
Go to the http://www.openacs.org website and look for Windows Installer.
I did this distribution for OpenACS and .LRN.
The same software is now used by ]project-open[
http://projop.dnsalias.com/documentation/install_windows
All the major components of my distribution, e.g. TCL, AOLserver, the
various modules, etc... are native Win32.
I added among the binaries some of tools/utilities used by the TCL code
(e.g. find, wget, etc...), some of these tools/utilities are Cygwin based.
The previous Windows installer for ]project-open[ was completely Cygwin
based. But that didn't work well because PostgreSQL on Cygwin was not enough
performant.
In two/three weeks I'll update my distribution by including all the lesson
learned when generating the ]project-open[ windows installer.
Hope it helps,
Maurizio
-----Original Message-----
From: AOLserver Discussion [mailto:AOLS...@LISTSERV.AOL.COM] On Behalf Of
Rusty Brooks
Sent: 03 November 2009 12:29 AM
To: AOLS...@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] is it necessary
Alexey Pechnikov
On Tuesday 03 November 2009 02:28:57 Rusty Brooks wrote:
> I've had a few customers who insisted on windows - usually it's because
> their in-house IT staff is windows only.
>
> A cygwin port would probably be good enough though, and maybe that's
> easier than a full-blown win32 native port?
Did you try the coLinux? This is windows service builded from modified
linux kernel. This did work fine for me some years ago. CoLinux is like
chroot and can start the image dumped from linux server.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Alexey Pechnikov
On Monday 02 November 2009 04:14:17 Tom Jackson wrote:
> On Fri, Oct 30, 2009 at 9:36 PM, Bas Scheffers <b...@scheffers.net> wrote:
> > I do this for a couple of sites, Apache's mod_proxy forwards stuff to
> > AOLserver. This is mostly where we have a scarcity of IPs.
> >
> > But that still means you have to jump through hoops to install it, learn how
> > to run it in production, etc.
> >
>
> It is strange that the most valid reason to use Apache is a lack of IP
> addresses. But it's true.
Why Apache? I'm using AOL Server cluster with single entry-point
managed by HAProxy. I did use Pound some times ago.
>
> > I'd love a being able to just say "apt-get install apache2-aolserver
> > apache2-aolserver-postgresql".
>
> As soon as apt-get blah-blah-blah starts installing software where I
> want it, with the options I want, I also would love it. But if I
> install an AOLserver for a client, they might want to keep their
> version for a few years, the next client might want the current
> version and a new postgresql. The apt-get stuff works exactly once per
> machine and it still doesn't give much flexibility. Eventually you
> have to learn how to do custom installs.
For AOL Server there are not additional packages now but it's not the
problem of AOL Server. We can build a set of packages. As example
aolserver4-openacs-framework
aolserver4-mbg-framework
...
And we can have different AOL Server builds:
$ apt-cache policy aolserver4
aolserver4:
Installed: 4.5.1-mobigroup.5
Candidate: 4.5.1-mobigroup.5
Version table:
*** 4.5.1-mobigroup.5 0
500 http://mobigroup.ru lenny/main Packages
100 /var/lib/dpkg/status
4.5.0-16.1 0
500 http://mirror.yandex.ru lenny/main Packages
The 4.5.1-mobigroup.5 is my own build with tcl 8.5 and some bugfixes. Is not
difficult to add other builds.
> I like the idea of a forward (caching) proxy, it fits in well with the
> filter type architecture in AOLserver.
I don't understand which tasks it can resolving?
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Tom Jackson
> On Saturday, October 31, 2009 10:30pm, "Dave Bauer" <da...@THEDESIGNEXPERIENCE.ORG> said:
>> Of course you can say apt-get install aolserver4 already.
> Of course you can, but then what? Then you still have this completely alien server in front of you that you will need to configure. It puts people off. being just another language and API an Apache environment is going to be much more appealing to most users.
>
> The vast majority of people that *use* LAMP and not developers, nor have any heroic sysadmin skills. They just download WordPress or Drupal or Gallery, dump it into their page root and away they go. They may tweak a few templates with PHP code in them, but that's it.
>
> That's the kind of simplicity AOLserver needs to grow. We live in an Apache world; if you can't beat them, join them...
I guess the question is: once you have made all these changes to
AOLserver, what exactly do you have left? The answer is Apache running
Tcl. Why not start with Tcl and run it under FastCGI? Which AOLserver
API do you wish to continue to use after you add on Apache? I have an
nsd emulation layer which replaces ns_conn, ns_return, etc, so that
most tcl pages run as expected, I have another adapter which allows
this layer to run inside of tclhttpd, which is similar to CGI. This
allows my tcl pages to run inside AOLserver, tclhttpd, tcpserver,
nstclsh, stand-along [socket] or [socket] with threads. It uses the
same startup script in every case.
What do I lose? Filters, modules, speed, ns_config.
If we could somehow get modules and ns_config to work with nstclsh, it
is relatively easy to replace the filter/registered proc functionality
(already done that too) in Tcl code.
So the only thing left is speed. I can wait a year and hardware
improvements will solve that one by itself.
But for me the big thing is the database API and connections. Only
AOLserver provides that piece, so someone would have to demonstrate
that modules would still work as they do in AOLserver before I could
imagine this working.
tom jackson
Tom Jackson
> Hello!
>
> On Monday 02 November 2009 04:14:17 Tom Jackson wrote:
>> On Fri, Oct 30, 2009 at 9:36 PM, Bas Scheffers <b...@scheffers.net> wrote:
>> > I do this for a couple of sites, Apache's mod_proxy forwards stuff to
>> > AOLserver. This is mostly where we have a scarcity of IPs.
>> >
>> > But that still means you have to jump through hoops to install it, learn how
>> > to run it in production, etc.
>> >
>>
>> It is strange that the most valid reason to use Apache is a lack of IP
>> addresses. But it's true.
>
> Why Apache? I'm using AOL Server cluster with single entry-point
> managed by HAProxy. I did use Pound some times ago.
This only applies if you must use Apache. Apache is obviously more
flexible than AOLserver in this area, but any proxy server would do.
The one area where Apache seems to beat AOLserver from a design
standpoint is serving many unrelated virtual hosts. AOLserver must
load each virtual host into memory even if you use the CGI module. Of
course, if the virtual hosts are all managed by the same admins, you
can do soft virtual hosting inside of a single AOLserver instance.
But, you can't allow 2+ admins under a single AOLserver
instance...unless you don't allow the admins to use untrusted code
which can access the AOLserver or Tcl API. For example, my
<tic-tac-toe> template system would allow admins to provide their own
templates without introducing security issues.
- Show quoted text -
I'm not sure who does the adding? The problem is when you want to
maintain two independent AOLservers on one machine. That is two
independent Tcl installations, two of everything. The apt bs works if
you use apt, what if you don't want to, or can't? You just substitute
understanding how to build AOLserver with the need to understand apt.
Neither one is particularly more or less complicated if you have to do
anything special.
>> I like the idea of a forward (caching) proxy, it fits in well with the
>> filter type architecture in AOLserver.
>
> I don't understand which tasks it can resolving?
Caching of expensive content: dynamic content which is used many times
before it actually changes, like the front page of a news site. Even
the time of day only changes once per second, if you get a 100 hits
per second, caching cuts your backend load by 99%.
tom jackson