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

[ Post a follow-up to this message ]

> 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

[ Post a follow-up to this message ]

> 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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

>> 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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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@lists
erv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subjec
t: field of your email blank.
>

[ Post a follow-up to this message ]