|
Home > Archive > AOL Webserver > September 2006 > AOLserver's documentation woes and its future
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]
| Author |
AOLserver's documentation woes and its future
|
|
| Dossy Shiobara 2006-09-01, 1:11 pm |
| I'd like to share with the community a comment made by someone at AOL:
|| My problems with AOLserver are:
||
|| 1) The lack of documentation, which is annoying, but could be fixed.
||
|| 2) The tiny userbase, which [AOL] simply can't fix. Not unless AOL
|| puts 10 times more support into the product than they ever have in
|| the past and that's not gonna happen.
I know that the sad state of the documentation has been a big problem
for a long time. I'd really like to hear suggestions from everyone as
to how we might go about solving it.
Does it all have to be written by one or two people? Can the work be
distributed? Where do we start? Should we take the old documentation
and just freshen it up? Do we need to start with a new draft Table of
Contents and start over? What is keeping folks from contributing (time,
expertise, money, something else)? What format do folks want: dead tree
books, online e-books, both, something else entirely?
With respect to the size of the community, what can we do to grow it?
We definitely need more evangelism: marketing, communication with the
press, white papers, etc. Do folks in the AOLserver community attend
trade shows and conferences? Which ones? Do you tell folks about
AOLserver? Why or why not?
If you have a commercial product built on top of AOLserver, do your
customers know this? Do you mention the existence of this community to
them? If not, why not?
I realize there are folks located all around the world, but if I
organized it, would folks be willing to travel for an AOLserver
Conference? Where would people want to attend it (excluding obvious
destinations like "Hawaii" and "on a cruise ship" that may be slightly
out of our reach right now, :-)? Would anyone be willing to volunteer
to help organize it?
Even if we can't achieve it, I'd like everyone to help put together a
plan and the roadmap for AOLserver into 2007. Not just development
milestones and features, but all of the project's activities that we
want to try and accomplish.
I'm far from ready to give up on AOLserver and I'm reaching out to
everyone to say ... if ever you wanted to help, now is the time. Share
your thoughts and I think together, we can all make this happen.
-- 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)
| |
| Janine Sisk 2006-09-01, 7:11 pm |
| Well... yes, all our customers who are technically savvy enough to
understand know that we use AOLserver. Unfortunately, the fact that
OpenACS requires AOLserver is a hindrance in the sales cycle, and
there have been repeated requests from many people over the years for
OpenACS to run under Apache (which is never going to happen). Part
of the problem is the association with AOL - rightly or wrongly, that
inspires a "fight or flight" response in many of the IT people we
talk to. But the biggest issue is that it's different, and
Enterprise customers generally don't want to take on a new web server
for their admins to have to learn and support.
As far as the community goes... I have been using AOLserver since
early 1999; that's 7.5 years. During that time, I have maybe looked
at the source a dozen times, if that, and usually I don't find what
I'm looking for. It's an application that requires specialized
domain knowledge to understand, written in a language I haven't
worked in professionally for almost 20 years. It's not where I can
spend my time most effectively. I think there are relatively few
people out there who really *want* to dive into the internals of a
web server, and most of them are working on Apache. So the
participating community does not have a huge pool of people to draw on.
Even writing documentation would be a big investment of time for me,
because in order to document something one has to really understand
what it does, and right now the only way to do that is to read the
source. Maybe it makes me a bad person, but I just don't have that
much time to invest in this.
I think we have a bit of a catch-22 situation here. There are only a
handful of people who are knowledgeable enough about AOLserver to
help those who are having trouble. Those people are overloaded and
are not able to provide the hand-holding needed by users who don't
know how to use debugging tools and fix their own problems. So
people either stop using AOLserver, or they learn to put up with or
work around problems they aren't able to fix on their own. And so
the community stays small, and enthusiasm for participating is dampened.
There were a lot more attempts at community participation years ago,
but they were mostly rebuffed. Patches being rejected for no good
reason used to be a fairly frequent topic on this list. That also
set a tone of people not wasting their time contributing which
probably persists to this day even though the person responsible is
long gone.
Unfortunately, it is much easier to describe the problem than it is
to find solutions. About the best suggestion I can think of is that
you may get more participation if you realize that although most of
us are developers, very few of us are AOLserver developers. It's not
enough to throw open the gates and invite us to participate. There
has to be some way for those who are so inclined to gain the basic
knowledge needed to be useful, and right now that's just not there.
My $0.02,
janine
On Sep 1, 2006, at 11:10 AM, Dossy Shiobara wrote:
> I'd like to share with the community a comment made by someone at AOL:
>
> || My problems with AOLserver are:
> ||
> || 1) The lack of documentation, which is annoying, but could be
> fixed.
> ||
> || 2) The tiny userbase, which [AOL] simply can't fix. Not unless AOL
> || puts 10 times more support into the product than they ever have in
> || the past and that's not gonna happen.
>
> I know that the sad state of the documentation has been a big problem
> for a long time. I'd really like to hear suggestions from everyone as
> to how we might go about solving it.
>
> Does it all have to be written by one or two people? Can the work be
> distributed? Where do we start? Should we take the old documentation
> and just freshen it up? Do we need to start with a new draft Table of
> Contents and start over? What is keeping folks from contributing
> (time,
> expertise, money, something else)? What format do folks want: dead
> tree
> books, online e-books, both, something else entirely?
>
> With respect to the size of the community, what can we do to grow it?
> We definitely need more evangelism: marketing, communication with the
> press, white papers, etc. Do folks in the AOLserver community attend
> trade shows and conferences? Which ones? Do you tell folks about
> AOLserver? Why or why not?
>
> If you have a commercial product built on top of AOLserver, do your
> customers know this? Do you mention the existence of this
> community to
> them? If not, why not?
>
> I realize there are folks located all around the world, but if I
> organized it, would folks be willing to travel for an AOLserver
> Conference? Where would people want to attend it (excluding obvious
> destinations like "Hawaii" and "on a cruise ship" that may be slightly
> out of our reach right now, :-)? Would anyone be willing to volunteer
> to help organize it?
>
> Even if we can't achieve it, I'd like everyone to help put together a
> plan and the roadmap for AOLserver into 2007. Not just development
> milestones and features, but all of the project's activities that we
> want to try and accomplish.
>
> I'm far from ready to give up on AOLserver and I'm reaching out to
> everyone to say ... if ever you wanted to help, now is the time.
> Share
> your thoughts and I think together, we can all make this happen.
>
> -- 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)
>
>
> --
> 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 2006-09-01, 7:11 pm |
| | |
| Andrew Piskorski 2006-09-01, 7:11 pm |
| On Fri, Sep 01, 2006 at 02:10:00PM -0400, Dossy Shiobara wrote:
> I know that the sad state of the documentation has been a big problem
> for a long time. I'd really like to hear suggestions from everyone as
> to how we might go about solving it.
As with code, one of the more effective ways to improve documentation
is often to have a clear and demanding customer for it. So, I have to
ask, internally at AOL (for Dossy) and/or in other development groups
(for everyone else), just how do new developers learn about AOLserver?
And does that happen often?
> Does it all have to be written by one or two people? Can the work be
I suspect that one or two experts must provide at least the editorial
voice and oversight. They probably also need to write at least the
tricky parts themselves, especially the brand new (and as yet little
used) features, and the more interesting non-API docs, like
explanations of the internal architecture and design, advice on how
and why to do things in particular ways, and the like.
> distributed? Where do we start? Should we take the old documentation
> and just freshen it up?
Yes, of course. The docs could use refreshing, corrections, and
additions for the new features. There's no reason to throw out all
the older info that's already there, and largely correct.
> Do we need to start with a new draft Table of Contents and start
> over?
Rather, I would say, add any missing sections you think SHOULD be
there to the table of contents, as a partial roadmap of what you'd
like to accomplish.
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
| |
| Tom Jackson 2006-09-01, 7:11 pm |
| Who would AOLserver appeal to the most?
My first guess would be Tcl programmers, but it might be easier to introduce
the API via libnsd. libnsd offers at least a few things:
Data structures:
ns_set
nsv arrays
ns_config (not sure if you can use this with just libnsd)
Mutex/Concurrent programming
Scheduled Procedures
Database Access
(Any comments on if/when/how you can load modules into a tclsh?)
How to appeal to new users?
Examples, examples, examples. I don't read a dictionary to learn a language.
One thing which should be easy for active programmers to contribute is code
examples: how do you use commands or solve problems.
I haven't contributed much in the way of documentation, but I have made
available many examples of how I use the API. One possible way of organizing
this would be to create a example server. There are usually three types of
code: library code, registered filters and procedures and script pages: both
tcl and adp. A directory structure in pageroot could be used to organize and
play around with various API (tcl, nsd, modules, application code). You might
be able to use the same group of pages to auto test the API. Probably my most
efficient method of developing a API is to write the proc on a tcl script
page and just reload the page between edits. Once done, the procedure is
moved into a library file. Instead of this, I could just leave the page as an
example of how to call/use the procedure.
I don't think anyone is going to have any luck selling AOLserver to someone
who could use Apache to do everything they want as efficiently as they need.
But what would be needed to sell AOLserver to those who could benefit? My
opinion is that we need examples of multi-server applications. Although there
are many small customers who would like to use existing software, larger
customers are more likely to realize that being able to handle growth (due to
success) is more important. It would be helpful if AOL could release (I know
they are getting close) nsdci and some kind of white paper to explain how
they can be used. Knowing that this information is publicly available could
be a good selling point.
tom jackson
| |
| John Buckman 2006-09-03, 1:11 pm |
| > I know that the sad state of the documentation has been a big problem
> for a long time. I'd really like to hear suggestions from everyone as
> to how we might go about solving it.
I want to chime in with a different viewpoint:
1) the documentation is actually excellent, it's just scattered
between old and new, it's just recent features are poorly
documented. A few common tasks need how-tos. Most open source
projects have little or no docs, only the the massive Apache-sized
stuff is a lot better than what aolserver has.
2) there is lots of good competition - everything from Ruby, Python
and Zope to LightHttpd is in the same kind of mind space --
alternatives to Apache that have cool ideas in them.
3) the name is a small problem -- I have to explain it to people, but
then they get excited by the realization "wow, if aol uses it, it
must be pretty good", so while aol is not known for open source
projects, it does serve as one hell of a reference customer
4) tcl is more of a problem, people just don't want to learn a language.
5) if there's one thing I think aolserver could do to get more people
to use it, it would be to put php in as a standard language, not as
cgi, but mod_php style, AND take all the groovy aolserver apis and
make them available to php commands. I know I can run php from cgi,
but it's in no way better than apache at that task. But... I'll bet
that aolserver running php as a primary language would be faster than
apache.
6) pick on apache's weak spots, most specifically, languages that are
cool but run very slowly in apache. Ruby is what comes to mind --
I'm seeing reports of massive scalability problems with Ruby under
apache due to the cgi architecture, and since languages are so easy
to glue into aolserver, that seems like a no-brainer.
7) in general, if aolserver was a great place to run the common web
languages in a fast, multithreaded way, and did well on the
benchmarks vs apache, I think the language zealots would begin
pushing aolserver as the best platform
8) BTW, I convinced my ex-company Lyris to give aolserver a try,
moving from tclhttpd, and Rusty (who's on this list) is doing a test-
port to aolserver right now. So, there definitely are companies
willing to experiment with aolserver.
-john
| |
| Bas Scheffers 2006-09-05, 7:11 am |
| On Sunday, September 3, 2006 16:58, John Buckman said:
> 2) there is lots of good competition - everything from Ruby, Python
> and Zope to LightHttpd is in the same kind of mind space --
> alternatives to Apache that have cool ideas in them.
Well, half of those actually run inside Apache, they are not really an
alternative to it.
> 3) the name is a small problem -- I have to explain it to people, but
I agree. Most people around me respect my knowledge and experience when it
comes to web applications, yet I still have a very hard time to convince
them this is good technology; let alone convincing them to use it
themselves...
> 4) tcl is more of a problem, people just don't want to learn a language.
I don't agree with this one, though! People learn new languages all the
time to use new technology; php and Ruby are good examples, very few
people learn these for any other reason than to create web apps. If they
hear about some cool new framework and get interested in it, they will
pick it up.
I know Tcl isn't "cool", but we all know it is far superior to PHP's mess
of 100 different commands that behave every so slightly different to
achieve pretty much the same task. It was my first language and I still
believe it is the best language fo any beginner. We should promote Tcl
hard.
> 6) pick on apache's weak spots, most specifically, languages that are
> cool but run very slowly in apache. Ruby is what comes to mind --
Not sure about running a "negative" campaign, so it has to be very subtle.
That said, there is nothing wrong with pointing out (with proof in
benchmarks!) that the same task in AOLserver Tcl runs rings around
anything in PHP.
As a joke about LAMP: "Linux, Aolserver, My own damn code & Postgres!" ;-)
What about the website? I *really* think we should move this to AOLserver;
we have to practice what we preach! Maybe just go with OpenACS? Any
experts on that who would want to be technical lead on that? If hosting is
a problem (I hope not at AOL!) I am perfectly willing to host it. I share
an underutilzed fast box on an even faster internet connection in
Telehouse in London and we'd have no problems with select members of this
community having logins to it.
Bas.
| |
| Dossy Shiobara 2006-09-05, 1:11 pm |
| On 2006.09.05, Bas Scheffers <bas@SCHEFFERS.NET> wrote:
> What about the website? I *really* think we should move this to AOLserver;
> we have to practice what we preach! Maybe just go with OpenACS? Any
> experts on that who would want to be technical lead on that? If hosting is
> a problem (I hope not at AOL!) I am perfectly willing to host it. I share
> an underutilzed fast box on an even faster internet connection in
> Telehouse in London and we'd have no problems with select members of this
> community having logins to it.
Lets do it. Lets get it all set up and ready to go, then we can request
the DNS admins at AOL to point aolserver.{com,net,org} there.
-- 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)
| |
| Rick Gutleber 2006-09-05, 1:11 pm |
| If AOL wants to sever its ties with AOLServer (and it looks like it
does) then a name change is probably in order. It's a shame because
there are good reasons for each to be associated with the other by
name. From my limited experience, I think the tool has benefitted from
tremendous talent and skill involved in creating and supporting it, but
has also suffered from a black sheep status and no longer being
whole-heartedly supported in its own right by the company as an
open-source project, but rather as "Here's something spiffy we use, if
you can do something with it, knock yourself out, but take it as is."
and that's about it. Releasing it to the OSS community was an
incredibly good thing, and I think sets a great example for the kinds of
things AOL wants to do and needs to do now. But it seems to me that it
is only somewhat supported, and mostly because it's still being used
in-house.
I know there was confusion around here when 4.5 was released as to its
disposition here at the company; there probably still is. I think AOL
could benefit greatly from embracing and actively supporting the tool
_even_ if they themselves phase out their use of it. In order to remake
itself as a Web 2.0 entity, the company is going to need to invest more
in technology in and of itself, as a means to germinate and nurture the
kinds of products and services that will set it apart from (and ahead
of) the competition.
If they don't want to, then the Open Source community should try to shop
it around to see if another corporate user could sponsor a core
development and documentation team. The problem, in my mind, is that
the arguments against using it are not based on technology. AOL might
have legitimate reasons to move away from it... I'm not in a position to
know or understand those reasons... but no one seems to be saying it
shouldn't be used because it doesn't, at the end of the day, work.
Just some ideas. As an AOL employee, I'd love to see what's best for
both the company and the tool. I think at this point, they probably
should admit their parting of ways and start to move on.
Support for more popular languages (come on, let's say it together, I
know it's hard, but "Tcl is not popular") is probably the most useful
long-term technical change that can be made. This isn't an indictment
on Tcl or a no-confidence vote, but just an attempt to be more open and
accommodating to users and (more importantly) potential users. And as
for the topic of the language you use, I would suggest reading this:
http://www.paulgraham.com/avg.html. Viva alternate programming
languages, or as Mr. Spock would say: Infinite Diversity in Infinite
Combinations.
Rick
Dossy Shiobara wrote:
> On 2006.09.05, Bas Scheffers <bas@SCHEFFERS.NET> wrote:
>
>
> Lets do it. Lets get it all set up and ready to go, then we can request
> the DNS admins at AOL to point aolserver.{com,net,org} there.
>
> -- Dossy
>
>
--
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.
| |
| Dossy Shiobara 2006-09-05, 1:11 pm |
| (Apologies for the long email ahead ... but, I think it's worth a quick
read.)
On 2006.09.05, Rick Gutleber <rgutleber11@AOL.COM> wrote:
> Support for more popular languages (come on, let's say it together, I
> know it's hard, but "Tcl is not popular") is probably the most useful
> long-term technical change that can be made.
Of course, the more popular languages weren't implemented with
embeddability (embedibility?) in mind. Tcl is one of the only mature
languages that can be safely embedded in a multi-threaded application.
Specifically, what I mean is, Tcl is one of a few languages that can
have multiple interpreters in the same process space executing
concurrently in multiple threads.
Python can be embedded, but according to this:
http://docs.python.org/api/api.html
8.1 Thread State and the Global Interpreter Lock
http://docs.python.org/api/threads.html
"The Python interpreter is not fully thread safe. In order to
support multi-threaded Python programs, there's a global lock that
must be held by the current thread before it can safely access
Python objects. [...]"
A global lock? There goes scalability and the benefits of embedding
Python. (You'd be better off running it in a separate process ala
FastCGI, AOLserver would gain no performance by embedding it, only
risk.)
Same problem with Ruby:
http://metaeditor.sourceforge.net/embed/
"ruby is not thread-safe. If you embed ruby into a multi-threaded
application then you will need to semaphore protect all access to
ruby. Warning: Insufficient semaphore protection can be hard
debuggable."
So, they're pointing out the need for a global lock, too. What's worse,
the Ruby interpreter uses global variables to manage interpreter state,
so even if you did embed it and use a global lock, you couldn't spin up
two instances of the interpreter in the same process, anyway!
PHP isn't even worth considering, really:
Re: [PHP-DEV] Re: php and Apache2
http://marc.theaimsgroup.com/?l=php...36540021355&w=2
"The major feature that draws people to Apache2 is threading. [...]
However, on UNIX there are a lot of basic libraries where thread
safety is an unknown. [...]
And yes, you could use the prefork mpm with Apache2 to avoid the
threading, and yes you could use a standalone fastcgi mechanism to
avoid the threading, but you are going out of your way to avoid the
defining characteristic of the web server you have decided to use."
Rasmus makes it very clear that the reason php is so popular and
powerful is its large list of third-party extensions that add a lot of
"out of the box" functionality for php developers. However, it's that
same attribute of php that keeps it from playing nicely, embedded in a
multi-threaded application.
Lets not forget this, too:
http://developers.slashdot.org/deve...8/0552240.shtml
"Jani Taskinen, one of the lead developers of the Zend Engine (the
engine that powers PHP), as well as a lead developer for the thread
safety system and other core components of the php project, has quit
in a relatively cryptic message to the php-internals mailing list.
Jani has been involved with php for about 6 years and his loss will
undoubtedly be a big blow for the php project."
It'll be interesting to see where the future of php takes it.
Now, lets look at Perl:
http://search.cpan.org/dist/perl/pod/perlembed.pod
"Now suppose we have more than one interpreter instance running at
the same time. This is feasible, but only if you used the Configure
option -Dusemultiplicity or the options -Dusethreads -Duseithreads
when building perl. [...]
Using -Dusethreads -Duseithreads rather than -Dusemultiplicity is
more appropriate if you intend to run multiple interpreters
concurrently in different threads, because it enables support for
linking in the thread libraries of your system with the
interpreter."
Oh, nice. I don't see any mention of using a globally shared lock to
prevent two PERL interpreters running concurrently. (This could just be
an omission from the docs, but I have the feeling it's not the case.)
So, of the "languages more popular than Perl" being Python, Ruby, PHP
and PERL ... PERL is the only suitable candidate for replacing Tcl in
AOLserver.
Considering that PERL is no longer the "flavor of the day" and has been
replaced by Python and Ruby amongst the "language geeks" and php amongst
the unwashed masses ... who really wants to go replacing AOLserver's
embedded Tcl with embedded Perl? How many months or years before people
see PERL like they see Tcl today (not popular, etc.)?
The irony here is so few people have even heard of Tcl that if it was
evangelized and marketed correctly, it could be brought to the
marketplace as a "new" language to replace Ruby and Python and PHP.
Write a slew of books, release a mound of free Tcl code and add simple
enhancements to Tcl like closures/lambdas and other language features
that'll make the language geeks go "ooh!" and the unwashed masses will
download all the free code they need ...
.... and then the cycle starts all over again.
After having said all this, I would like to explore the idea of
Server-side JavaScript (SSJS):
http://en.wikipedia.org/wiki/Server-side_JavaScript
Netscape took a shot at this with its LiveWire stuff back in
1996. Now that it's 10 years later, could it be the right time to try
again? (I wouldn't try to re-implement LiveWire, but use what we've
learned about embedding a scripting language inside a webserver and use
JS as the language.)
SpiderMonkey: JavaScript C Engine Embedder's Guide
http://developer.mozilla.org/en/doc...edder%27s_Guide
"The run time is the space in which the variables, objects, and
contexts used by your application are maintained. A context is the
script execution state for a thread used by the JS engine. Each
simultaneously existent script or thread must have its own context.
A single JS run time may contain many contexts, objects, and
variables."
I'd like to work on an AOLserver module and ADP parser (extend the fancy
parser to recognize "<?js ... ?>") to embed SpiderMonkey, as a start.
I'd argue that there's more JavaScript expertise out there today than
there is Java, PHP, etc. because with the rise of RIA's and AJAX
techniques, regardless of what backend language you use, you still have
to use some amount of JavaScript. To me, it makes sense to leverage
that same JS knwoledge (and code!) on the server side, too.
IMHO, this change could put AOLserver back in the beauty pageant.
As always, I welcome any comments or criticisms or flaming of my
half-baked off-the-cuff email-to-the-whole-list ideas I presented here.
I know there's plenty of them ... :-)
-- 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)
| |
| Bas Scheffers 2006-09-05, 1:11 pm |
| On Tuesday, September 5, 2006 15:50, Rick Gutleber said:
> Support for more popular languages (come on, let's say it together, I
> know it's hard, but "Tcl is not popular") is probably the most useful
> long-term technical change that can be made. This isn't an indictment
As long as it is anything but PHP! This is not because I do not like PHP
very much but because - even though it is the most popular language - is
the only language that *doesn't* make sens to use in AOLserver.
I know this sounds strange, but think about : throughout its evolution, PHP
has always been closely tied to Apache. So you could integrate it with
AOLserver and expose the AOLserver API in it, but who would use it? The
majority of people will always use Apache with php and why would you write
a php app that isn't compatible with Apache? And without using the API,
what advantage does AOLserver have over Apache 2 running PHP?
Languages like PERL and Ruby are much more likely candidates. The only
"standard" thing when it comes to those for interacting with the server
they are running in are "CGI variables". If you want to do it right you'd
implement Perl:DBI to under the hood use on-the-fly generated AOLserver
pools, but that's about it.
That said: I still believe AOLserver is all about Tcl and the tight
integration with it. It would be a shame to fragment the community;
"sorry, can't help you, I only use PERL in AOLserver", etc. Add too many
of these things and AOLserver will just because another jack of all trades
like Apache.
Either make AOLserver an Apache module that kicks every other module's
arse (so much so Tcl is cool again) or keep it like it is, except better
documented and easier to get started with.
Just my thoughts,
Bas.
| |
| Nathan Folkman 2006-09-05, 1:11 pm |
| dossy@PANOPTIC.COM wrote:
> (Apologies for the long email ahead ... but, I think it's worth a quick
> read.)
>
> On 2006.09.05, Rick Gutleber <rgutleber11@AOL.COM> wrote:
>
>
> Of course, the more popular languages weren't implemented with
> embeddability (embedibility?) in mind. Tcl is one of the only mature
> languages that can be safely embedded in a multi-threaded application.
>
> Specifically, what I mean is, Tcl is one of a few languages that can
> have multiple interpreters in the same process space executing
> concurrently in multiple threads.
>
> Python can be embedded, but according to this:
>
> http://docs.python.org/api/api.html
>
> 8.1 Thread State and the Global Interpreter Lock
> http://docs.python.org/api/threads.html
>
> "The Python interpreter is not fully thread safe. In order to
> support multi-threaded Python programs, there's a global lock that
> must be held by the current thread before it can safely access
> Python objects. [...]"
>
> A global lock? There goes scalability and the benefits of embedding
> Python. (You'd be better off running it in a separate process ala
> FastCGI, AOLserver would gain no performance by embedding it, only
> risk.)
>
> Same problem with Ruby:
>
> http://metaeditor.sourceforge.net/embed/
>
> "ruby is not thread-safe. If you embed ruby into a multi-threaded
> application then you will need to semaphore protect all access to
> ruby. Warning: Insufficient semaphore protection can be hard
> debuggable."
>
> So, they're pointing out the need for a global lock, too. What's worse,
> the Ruby interpreter uses global variables to manage interpreter state,
> so even if you did embed it and use a global lock, you couldn't spin up
> two instances of the interpreter in the same process, anyway!
>
> php isn't even worth considering, really:
>
> Re: [PHP-DEV] Re: php and Apache2
> http://marc.theaimsgroup.com/?l=php...36540021355&w=2
>
> "The major feature that draws people to Apache2 is threading. [...]
> However, on UNIX there are a lot of basic libraries where thread
> safety is an unknown. [...]
>
> And yes, you could use the prefork mpm with Apache2 to avoid the
> threading, and yes you could use a standalone fastcgi mechanism to
> avoid the threading, but you are going out of your way to avoid the
> defining characteristic of the web server you have decided to use."
>
> Rasmus makes it very clear that the reason php is so popular and
> powerful is its large list of third-party extensions that add a lot of
> "out of the box" functionality for php developers. However, it's that
> same attribute of php that keeps it from playing nicely, embedded in a
> multi-threaded application.
>
> Lets not forget this, too:
>
> http://developers.slashdot.org/deve...8/0552240.shtml
>
> "Jani Taskinen, one of the lead developers of the Zend Engine (the
> engine that powers PHP), as well as a lead developer for the thread
> safety system and other core components of the php project, has quit
> in a relatively cryptic message to the php-internals mailing list.
> Jani has been involved with php for about 6 years and his loss will
> undoubtedly be a big blow for the php project."
>
> It'll be interesting to see where the future of php takes it.
>
> Now, lets look at Perl:
>
> http://search.cpan.org/dist/perl/pod/perlembed.pod
>
> "Now suppose we have more than one interpreter instance running at
> the same time. This is feasible, but only if you used the Configure
> option -Dusemultiplicity or the options -Dusethreads -Duseithreads
> when building perl. [...]
>
> Using -Dusethreads -Duseithreads rather than -Dusemultiplicity is
> more appropriate if you intend to run multiple interpreters
> concurrently in different threads, because it enables support for
> linking in the thread libraries of your system with the
> interpreter."
>
> Oh, nice. I don't see any mention of using a globally shared lock to
> prevent two PERL interpreters running concurrently. (This could just be
> an omission from the docs, but I have the feeling it's not the case.)
>
> So, of the "languages more popular than Perl" being Python, Ruby, PHP
> and PERL ... PERL is the only suitable candidate for replacing Tcl in
> AOLserver.
>
> Considering that PERL is no longer the "flavor of the day" and has been
> replaced by Python and Ruby amongst the "language geeks" and php amongst
> the unwashed masses ... who really wants to go replacing AOLserver's
> embedded Tcl with embedded Perl? How many months or years before people
> see PERL like they see Tcl today (not popular, etc.)?
>
> The irony here is so few people have even heard of Tcl that if it was
> evangelized and marketed correctly, it could be brought to the
> marketplace as a "new" language to replace Ruby and Python and PHP.
> Write a slew of books, release a mound of free Tcl code and add simple
> enhancements to Tcl like closures/lambdas and other language features
> that'll make the language geeks go "ooh!" and the unwashed masses will
> download all the free code they need ...
>
> ... and then the cycle starts all over again.
>
> After having said all this, I would like to explore the idea of
> Server-side JavaScript (SSJS):
>
> http://en.wikipedia.org/wiki/Server-side_JavaScript
>
> netscape took a shot at this with its LiveWire stuff back in
> 1996. Now that it's 10 years later, could it be the right time to try
> again? (I wouldn't try to re-implement LiveWire, but use what we've
> learned about embedding a scripting language inside a webserver and use
> JS as the language.)
>
> SpiderMonkey: JavaScript C Engine Embedder's Guide
> http://developer.mozilla.org/en/doc...edder%27s_Guide
>
> "The run time is the space in which the variables, objects, and
> contexts used by your application are maintained. A context is the
> script execution state for a thread used by the JS engine. Each
> simultaneously existent script or thread must have its own context.
> A single JS run time may contain many contexts, objects, and
> variables."
>
> I'd like to work on an AOLserver module and ADP parser (extend the fancy
> parser to recognize "<?js ... ?>") to embed SpiderMonkey, as a start.
>
> I'd argue that there's more JavaScript expertise out there today than
> there is Java, PHP, etc. because with the rise of RIA's and AJAX
> techniques, regardless of what backend language you use, you still have
> to use some amount of JavaScript. To me, it makes sense to leverage
> that same JS knwoledge (and code!) on the server side, too.
>
> IMHO, this change could put AOLserver back in the beauty pageant.
>
> As always, I welcome any comments or criticisms or flaming of my
> half-baked off-the-cuff email-to-the-whole-list ideas I presented here.
> I know there's plenty of them ... :-)
>
> -- Dossy
>
>
I actually started some of this work in the form of an extension for the
nsproxy that would allow you to evaluate chunks of JavaScript code. I'll
see if I can actually find the code and check it in. That aside, the
SpiderMonkey stuff is pretty good and easy to embed.
- n
| |
| Tom Jackson 2006-09-05, 1:11 pm |
| This has been a pretty wide ranging discussion, now I'm starting to wonder a
little bit, maybe worry a little bit.
There seems to be at least one misconception about the product AOLserver,
which should be put to rest:
That is about language choice and the ability of introducing new scripting
languages into AOLserver.
AOLserver is a Tcl application, like Expect. That means that the C code uses
Tcl C APIs extensively, for nearly everything. Where the Tcl C APIs fail,
they have been supplemented with extensions in C, parts of which have been
exposed to the Tcl C and Tcl scripting APIs.
Adding another language would be on average more difficult than starting from
scratch because you would have to rewrite the entire application, and somehow
try to shoehorn the conventions of another language into the AOLserver/Tcl
conventions. In addition, most languages were not designed to be used like
Tcl for this purpose.
However if we could snap our collective fingers and have a multi-language
AOLserver tomorrow it would instantly be a huge minus. Because it isn't clear
how you would get two scripting languages to work togeather, you would have
to choose which one you want to use. You would lose everything written in the
other language. The only upside would be that we could have our own little
language war right here.
tom jackson
| |
| Jean-Fabrice RABAUTE 2006-09-05, 1:11 pm |
| > On Tuesday, September 5, 2006 15:50, Rick Gutleber said:
> As long as it is anything but PHP! This is not because I do not like PHP
> very much but because - even though it is the most popular language - is
> the only language that *doesn't* make sens to use in AOLserver.
>
> I know this sounds strange,
Yes, really strange... I don't agree.
My 2 cents : One example :
I have one webserver at home and only 1 public IP.
I have some web sites on php and some very few intranet pages on
aolserver/TCL.
I wanted to use aolserver, and virtual hosts.
Because for personal use I prefer to use aolserver/TCL rather than
apache/PHP.
Bad.. php and virtual hosting in aolserver are not working.
So... I am using Apache, and recoded quickly the few intranet tcl pages
(about 10 pages) in php.
I still do not like what I did, because I am just not using aolserver
anymore.
My customers keep me very busy ( :-( ) and I didn't find time to hack the
php module to make it work with aolserver virtual hosts (if it can be done),
but I would love to do it when I get time.
(By the way, I have also a pg util module I have developed that I should
make public...)
So, handling php in aolserver could have the advantage of giving the
oppotunity to a lot of "geeks" to try aolserver and give it some visibility.
You may strongly disagree ;-). I am a very bad marketing guy.
Regards / Cordialement
====================
Jean-Fabrice Rabaute
CORE SERVICES :: Software/Web development & Consulting services
http://www.core-services.fr - {Enjoy the future today}
http://www.debugbar.com : The most advanced WEB development tool for
Internet Explorer
http://www.prix-piscine.com : Le meilleur site sur le monde de la piscine
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/437 - Release Date: 04/09/2006
| |
| John Buckman 2006-09-05, 1:11 pm |
| Perl thread safety has never been properly debugged. In fact, that
was the reason I moved from PERL to Tcl many years back. I had
assumed that Python had fixed the global semaphore thing from when I
looked at it 8 years ago, but no.
Ok, Dossy, I buy your argument that the other pop languages aren't
going to perform better because of their thread safety issues.
Your server-side javascript argument is *very* interesting. It could
potentially make AJAX programming quite a bit easier and there are
some excellent debugging tools for Javascript.
One thing I really miss in the Aolserver/Tcl world is a good debugger
-- "puts" isn't such a good alternative :D. Javascript, I believe,
has nice development environments and debuggers available. It'd also
be nice to have a wider world of source code available to us, as Tcl
has a lot, but nothing compared to the Perl/PHP world.
> IMHO, this change could put AOLserver back in the beauty pageant.
>
> As always, I welcome any comments or criticisms or flaming of my
> half-baked off-the-cuff email-to-the-whole-list ideas I presented
> here.
> I know there's plenty of them ... :-)
>
I think you nailed it. It's the obvious solution, a very strong
direction for aolserver to go.
-john
| |
| Titi Ala'ilima 2006-09-05, 1:11 pm |
| Gleaning from this conversation a few main points/questions, with a couple cents of my own thrown in:
1) AOLserver probably needs a new name. Something that uses the NS initials would be ideal so that all those ns_* commands actually make sense again. Could we resurrect the NaviServer name?
2) The biggest bang for our buck would be improving the Tcl language and the codebase available for it rather than bringing in another popular language. It took Rails to put Ruby on the map. What would our Rails be?
3) What other features does AOLserver lack that would tap into current trends, or possibly create future ones? Server-side JS is interesting, "Comet" support seems like a good candidate?
4) Who could sponsor AOLserver development apart from AOL? Does anyone know of anyone with a large deployment of AOLserver?
5) Which will come first, Tcl gaining in popularity or AOLserver, or do they both need to grow together?
6) If AOLserver remains a targeted product, as it seems right now it should, it's usefulness will be limited by what can run on it, and what can integrate well with it. Which is fine, but we need to have that clear in our minds as we proceed. I don't th
ink we want to topple Apache per se. We want AOLserver to carve out its own path, and if along the way it makes Apache, etc. irrelevant then great!
-Titi
| |
| Jeff Hobbs 2006-09-05, 1:11 pm |
| John Buckman wrote:
> PERL thread safety has never been properly debugged. In fact, that
> was the reason I moved from PERL to Tcl many years back. I had
> assumed that Python had fixed the global semaphore thing from when I
> looked at it 8 years ago, but no.
>
> Ok, Dossy, I buy your argument that the other pop languages aren't
> going to perform better because of their thread safety issues.
I agree. I still find it somewhat odd when the PERL guys here rebuff any
attempts to rely on threading. PERL actually has a pthread_atfork function,
with much coarser grained threads (though still true native threads), but they
do not have much confidence in the stability of the threading. Python and
Ruby have cheated themselves by not taking advantage of native threads
(although I'm sure that makes things much easier).
> Your server-side javascript argument is *very* interesting. It could
> potentially make AJAX programming quite a bit easier and there are
> some excellent debugging tools for Javascript.
>
> One thing I really miss in the Aolserver/Tcl world is a good debugger
> -- "puts" isn't such a good alternative :D. Javascript, I believe,
> has nice development environments and debuggers available. It'd also
> be nice to have a wider world of source code available to us, as Tcl
> has a lot, but nothing compared to the Perl/PHP world.
The Tcl Dev Kit Debugger should be able to be inserted into the AOLServer
environment for effective debugging. You currently couldn't do that with
Komodo, but if there was demand, we could make some modifications. However,
TDK can handle multiple simultaneous debugging sessions, so it should really
be adept at the debugging needs of something like AOLServer.
Jeff
>
> I think you nailed it. It's the obvious solution, a very strong
> direction for aolserver to go.
>
> -john
| |
| Tom Jackson 2006-09-05, 1:11 pm |
| On Tuesday 05 September 2006 08:41, Dossy Shiobara wrote:
> (Apologies for the long email ahead ... but, I think it's worth a quick
> read.)
All very well said! I have done a number of language surveys over the years to
find one that was thread-safe, fast and easy to extend. Tcl is the only one I
have ever found, except for Java. Java is just too much for me to deal with,
and you still lose easy access to all the C libraries that are developed. For
anyone wanting to write their own network application but leverage the most
code, AOLserver/Tcl can't be beat. If you want to download and install a
bulletin board for your website, AOLserver isn't a great choice. Actually, it
might be best to just rent web hosting and get your bbs. But this isn't why
most of the AOLserver users are using AOLserver! Adding toy languages isn't
going to help. (As much as we have to get real about how 'uncool' Tcl might
be, we have to get real about these toy/specialized languages: they were
never designed for this scale of operation.)
I like the idea of an embeded JavaScript. It is obvious (or is it?) that with
the isolated context, there would be no ability for this to be a server wide
language, and no attempt to glue Tcl and JavaScript togeather. It sounds very
much like nsproxy, as Nathan said he even worked on this idea.
Anyway, if there was a push to market AOLserver, start with marketing the
known long term strengths of AOLserver. Most 'choosers' of AOLserver did so
because it offered a relatively clean environment for development. The market
is for companies that want to produce a service and/or who plan on tending to
customers who don't want to do their own development. If you try to do this
development with Apache and a bunch of modules, you run the risk that, first,
your product will look unoriginal and second, that someone could easily copy
it (and third or zeroth: it takes too long to develop or doesn't integrate
well, so it never takes off).
tom jackson
| |
| Janine Sisk 2006-09-05, 1:11 pm |
| On Sep 5, 2006, at 7:50 AM, Rick Gutleber wrote:
> If AOL wants to sever its ties with AOLServer (and it looks like it
> does)
I am most curious about this statement. Does AOL truly want to move
away from using AOLserver internally (which would seem to be the case
if they want to sever ties with it), and if so, what are they going
to be replacing it with?
janine
| |
| Jon Griffin 2006-09-05, 1:11 pm |
| One thing that might help is a feature chart of what PHP, Ruby etc have
that TCL/AOL don't.
This should include things like modules. I think there is a
misconception that PHP/Ruby et al have many more modules. They do but
most are absolute POS's. Written by teenagers with no real world
experience. Also, with OpenACS, alot of code is already written. Maybe
we could pull some of the stuff out and release it as snippets etc.
tcllib and xotcl are also full of stuff and run native in aol, so I
think it is as much a marketing issue as a technology one.
| |
| Rick Gutleber 2006-09-05, 1:11 pm |
| Titi Ala'ilima wrote:
> Gleaning from this conversation a few main points/questions, with a couple cents of my own thrown in:
>
> 1) AOLserver probably needs a new name. Something that uses the NS initials would be ideal so that all those ns_* commands actually make sense again. Could we resurrect the NaviServer name?
>
How about The NuffSaid server. Why should you use it? It's good. It's
got Tcl. 'Nuff said.
Sorry I read a lot of Marvel comics in the day.
> 2) The biggest bang for our buck would be improving the Tcl language and the codebase available for it rather than bringing in another popular language. It took Rails to put Ruby on the map. What would our Rails be?
>
I would be careful to say "improve upon, or enchance the Tcl libraries"
rather than the language.
> 3) What other features does AOLserver lack that would tap into current trends, or possibly create future ones? Server-side JS is interesting, "Comet" support seems like a good candidate?
>
> 4) Who could sponsor AOLserver development apart from AOL? Does anyone know of anyone with a large deployment of AOLserver?
>
I think it would take no more than some web space and, at best,
subsidizing a full-time developer or three.
> 5) Which will come first, Tcl gaining in popularity or AOLserver, or do they both need to grow together?
>
> 6) If AOLserver remains a targeted product, as it seems right now it should, it's usefulness will be limited by what can run on it, and what can integrate well with it. Which is fine, but we need to have that clear in our minds as we proceed. I don't
think we want to topple Apache per se. We want AOLserver to carve out its own path, and if along the way it makes Apache, etc. irrelevant then great!
>
Each tool has its own strengths, and you should play to those
strengths. When you try to be everything to everyone you end up being
some things to some people and loved by no one. Look at Microsoft's
"edlin 2007" with built in Javascript and VB-scripting, hooks into Win32
and the driver layer and a 37MB run-time on top of .NET 3.0. Oh, and it
requires Monad, VS2007 and to be installed on Vista Server for full
functionality. It doesn't have full-screen editing, but you can use it
write a virus in 17 lines of code.
Like you said: Don't approach AOLServer as something to make people
want to chuck Apache. First make it something to attract new users for
new projects... if it does that good enough, it will start to replace
Apache on its own.
> -Titi
>
>
> --
> 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 2006-09-05, 1:11 pm |
| On 5 Sep 2006, at 17:22, Jean-Fabrice RABAUTE wrote:
> I have one webserver at home and only 1 public IP.
> I have some web sites on php and some very few intranet pages on
> aolserver/TCL.
> I wanted to use aolserver, and virtual hosts.
I simply solve this (in various places) by having apache listen on
the one IP and using mod_proxy to forward requests for certain urls
or name-based virtual hosts to AOLserver, which works a treat!
Cheers,
Bas.
| |
| Bas Scheffers 2006-09-05, 1:11 pm |
| On 5 Sep 2006, at 17:57, Titi Ala'ilima wrote:
> 1) AOLserver probably needs a new name. Something that uses the NS
> initials would be ideal so that all those ns_* commands actually
> make sense again. Could we resurrect the NaviServer name?
Already taken! (OpenSource fork-without-anyone-from-AOL-interfering
of AOLserver)
Bas.
| |
| Titi Ala'ilima 2006-09-05, 1:11 pm |
| Rick Gutleber wrote:
> I would be careful to say "improve upon, or enchance the Tcl libraries"
> rather than the language.
I mean improving the language as well. As Dossy said, there are a few things that could be added to the language that would "make the language geeks go 'ooh!'", and a few others that would just make life a little more powerful. This is the sort of stuff
that most of us can't take as active a role in doing, but they would still make a big difference.
> I think it would take no more than some web space and, at best,
> subsidizing a full-time developer or three.
My question is aimed at finding out who would have the resources and motivation to subsidize developers?
-T.
| |
| Dossy Shiobara 2006-09-05, 1:11 pm |
| On 2006.09.05, Jeff Hobbs <jeffh@ACTIVESTATE.COM> wrote:
> The Tcl Dev Kit Debugger should be able to be inserted into the
> AOLServer environment for effective debugging. You currently couldn't
> do that with Komodo, but if there was demand, we could make some
> modifications. However, TDK can handle multiple simultaneous
> debugging sessions, so it should really be adept at the debugging
> needs of something like AOLServer.
While I've used plenty of different debuggers in the past, I've always
done it out of desperation ... due to lack of any other short-term
alternatives. Linus Torvalds has recently written something I've tried
to put into words for a long time:
http://linuxmafia.com/faq/Kernel/li...ard-speech.html
"[...] I happen to believe that not having a kernel debugger forces
people to think about their problem on a different level than with a
debugger. I think that without a debugger, you don't get into that
mindset where you know how it behaves, and then you fix it from
there. Without a debugger, you tend to think about problems another
way. You want to understand things on a different level. [...]"
This is not a knock against hte TDK and its debugger, or against folks
who go to bed at night having sexy dreams about their favorite debugger.
It's about why we end up in situations where we even feel a debugger is
necessary.
I'm just as much of a bastard as Linus, as I don't particularly care
about AOLserver or Tcl's debugger availability ... for mostly the same
reasons ... but, I'm not against code in AOLserver supporting it. I'd
be happy to help make it happen, but I'd have a hard time believing that
once it was available, people would really make use of the feature. The
kinds of problems that people want to use a debugger for aren't going to
be solved by using the debugger. They're the kind that require deeper
understanding of the problem. Better understanding of what the code
actually does vs. what you believe it's supposed to do, then making the
right modifications to the code so that what it does is what it's
supposed to do, etc.
-- 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 2006-09-05, 1:11 pm |
| On 2006.09.05, Janine Sisk <janine@FURFLY.NET> wrote:
> On Sep 5, 2006, at 7:50 AM, Rick Gutleber wrote:
>
>
> I am most curious about this statement. Does AOL truly want to move
> away from using AOLserver internally (which would seem to be the case
> if they want to sever ties with it), and if so, what are they going
> to be replacing it with?
To avoid any legal troubles, I suggest all AOL employees refrain from
discussing this subject. The answer to Janine's question (as much as
I'd love to discuss it) isn't public information.
Disclosing proprietary information is a violation of SBC guidelines,
etc., etc.
(Janine: I'm sorry I have to kill this line of discussion from the AOL
side, but it's necessary.)
Of course, non-AOL employees are free to speak and speculate all you
want. We just can't confirm or deny any of it.
-- 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)
| |
| Nathan Folkman 2006-09-05, 7:11 pm |
| bas@SCHEFFERS.NET wrote:
> On 5 Sep 2006, at 17:57, Titi Ala'ilima wrote:
> Already taken! (OpenSource fork-without-anyone-from-AOL-interfering of
> AOLserver)
Maybe we should all focus on NaviServer going forward? Those guys have
done a good job backporting work that's been done to the AOLserver head.
Just a thought.
- n
>
> Bas.
>
>
> --
> 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.
| |
| Titi Ala'ilima 2006-09-05, 7:11 pm |
| How long ago did this fork take place? If AOL does indeed drop AOLserver and we rebrand it, are there any reasons other than the work involved to maintain a forked code/user base?
-Titi
-----Original Message-----
From: Bas Scheffers [mailto:bas@SCHEFFERS.NET]
Sent: Tuesday, September 05, 2006 1:45 PM
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] AOLserver's documentation woes and its future
On 5 Sep 2006, at 17:57, Titi Ala'ilima wrote:
> 1) AOLserver probably needs a new name. Something that uses the NS
> initials would be ideal so that all those ns_* commands actually
> make sense again. Could we resurrect the NaviServer name?
Already taken! (OpenSource fork-without-anyone-from-AOL-interfering
of AOLserver)
Bas.
| |
| Dossy Shiobara 2006-09-05, 7:11 pm |
| On 2006.09.05, Titi Ala'ilima <tigre@OHO.COM> wrote:
> I mean improving the language as well. As Dossy said, there are a few
> things that could be added to the language that would "make the
> language geeks go 'ooh!'", and a few others that would just make life
> a little more powerful. This is the sort of stuff that most of us
> can't take as active a role in doing, but they would still make a big
> difference.
I think the active role we can all particpate in is coming up with a
concrete list of changes that we'd like to see.
I'm not saying this is an easy task, but is the necessary first step in
the process. We need focus.
> My question is aimed at finding out who would have the resources and
> motivation to subsidize developers?
How about bootstrapping a small non-profit organization (ala Mozilla
Foundation) that could collect funds to support further development?
Could this work? I think finding a single large benefactor like AOL
will be tough, but if we can pool together a bunch of small
contributions, that might help grease the wheels enough to get more
attention (and more funding).
-- 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)
| |
| Dave Bauer 2006-09-05, 7:11 pm |
| On 9/5/06, Titi Ala'ilima <tigre@oho.com> wrote:
> Rick Gutleber wrote:
>
> I mean improving the language as well. As Dossy said, there are a few things that could be added to the language that would "make the language geeks go 'ooh!'", and a few others that would just make life a little more powerful. This is the sort of stu
ff that most of us can't take as active a role in doing, but they would still make a big difference.
Don't forget to look at XoTcl which runs just fine in AOLserver.
http://media.wu-wien.ac.at/
>
--
Dave Bauer
dave@solutiongrove.com
http://www.solutiongrove.com
| |
| Bas Scheffers 2006-09-05, 7:11 pm |
| On 5 Sep 2006, at 18:54, Dossy Shiobara wrote:
> Of course, non-AOL employees are free to speak and speculate all you
> want. We just can't confirm or deny any of it.
Here goes my speculation then!
From between the lines in the past, I picked up that AOL business
units are getting a bit of freedom to choose technologies. Probably
not in the least because like other "portals" AOL does buy existing
tech; if you buy a small website with a service you want to add to
your portfolio and get to market quickly, you just buy it and don't
go and port it all to AOLserver.
I am sure that on top of that even for "from scratch" products,
business unit managers probably like "hot" tech too and try their
very best not to use AOLserver at times.
Though probably there is an *aweful* lot of code in AOL that is
completely dependent on AOLserver and I'll end my speculation with
saying that AOL won't be offloading AOLserver any time soon, even if
they scale back some future ("cool") developments.
But that shouldn't stop anyone in the comunity from implementing
these, though!
Bas.
| |
| Tom Jackson 2006-09-05, 7:11 pm |
| On Tuesday 05 September 2006 11:06, Titi Ala'ilima wrote:
> How long ago did this fork take place? If AOL does indeed drop AOLserver
> and we rebrand it, are there any reasons other than the work involved to
> maintain a forked code/user base?
The current code is in very great shape. That means more than few bugs: it
means that the code is easy to read and is well organized and mature.
The main problem with any fork is you loose the talent of those who made the
product interesting to us in the first place. If AOL stops development, you
don't necessarily have to introduce the stigma of a 'fork' into the
discussion. It is more of a continuation. (Maybe call the continued project
Phoenix). It is easy to talk about the possibilities, but I would like to ask
again that any soon-to-be-released code from AOL be released asap.
I think the main issue with going forward with development outside of AOL
would be maintaining control over the core development. Probably the first
task would be to write a document of how everything works as a whole.
tom jackson
| |
| Titi Ala'ilima 2006-09-05, 7:11 pm |
| Sorry I was unclear. I was actually wondering whether or not we should just merge with NaviServer so as to consolidate the code/user base.
-Titi
-----Original Message-----
From: Tom Jackson [mailto:tom@RMADILO.COM]
Sent: Tuesday, September 05, 2006 3:43 PM
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] AOLserver's documentation woes and its future
On Tuesday 05 September 2006 11:06, Titi Ala'ilima wrote:
> How long ago did this fork take place? If AOL does indeed drop
> AOLserver and we rebrand it, are there any reasons other than the work
> involved to maintain a forked code/user base?
The current code is in very great shape. That means more than few bugs: it
means that the code is easy to read and is well organized and mature.
The main problem with any fork is you loose the talent of those who made the
product interesting to us in the first place. If AOL stops development, you
don't necessarily have to introduce the stigma of a 'fork' into the
discussion. It is more of a continuation. (Maybe call the continued project
Phoenix). It is easy to talk about the possibilities, but I would like to ask
again that any soon-to-be-released code from AOL be released asap.
I think the main issue with going forward with development outside of AOL
would be maintaining control over the core development. Probably the first
task would be to write a document of how everything works as a whole.
tom jackson
| |
| John Buckman 2006-09-05, 7:11 pm |
| On Sep 5, 2006, at 6:00 PM, Jeff Hobbs wrote:
>
> The Tcl Dev Kit Debugger should be able to be inserted into the
> AOLServer
> environment for effective debugging. You currently couldn't do
> that with
> Komodo, but if there was demand, we could make some modifications.
> However,
> TDK can handle multiple simultaneous debugging sessions, so it
> should really
> be adept at the debugging needs of something like AOLServer.
Jeff, I agree, BUT feel free to express my vote for a Mac OSX version
of Tcl Dev Kit. <grin>
Komodo is on OSX, but as you indicated, the Komodo Tcl debugger won't
work with aolserver (I worked with your activestate tech support
folks and they said it wasn't supported)
As to "why a debugger for aolserver"?
Any large web-based application shares many of the same complexity
problems of traditional applications, and from my C++ days, I learned
that I should never leave code in that I hadn't stepped through at
least once.
Lots of the bugs on BookMooch (22,000 lines of Tcl procs at launch)
have been logic errors, and in the beta and first month of launching
BookMooch, my bug database reports 414 separate bugs fixed. That's a
lot of code, and a proper debugger is nice.
One nice thing tclhttpd has is a debug mode that gives you a stack
track, and a few other introspection features when a Tcl error
occurs. Might be worth borrowing the concept.
If it weren't for Komodo doing syntax checks as I type my Tcl code,
I'm sure I'd have many more bugs (that's an amazing feature, folks,
if you don't know about it)
-john
| |
| Dave Bauer 2006-09-06, 1:11 am |
| On 9/5/06, John Buckman <john@magnatune.com> wrote:
>
> As to "why a debugger for aolserver"?
>
> Any large web-based application shares many of the same complexity
> problems of traditional applications, and from my C++ days, I learned
> that I should never leave code in that I hadn't stepped through at
> least once.
>
> Lots of the bugs on BookMooch (22,000 lines of Tcl procs at launch)
> have been logic errors, and in the beta and first month of launching
> BookMooch, my bug database reports 414 separate bugs fixed. That's a
> lot of code, and a proper debugger is nice.
>
> One nice thing tclhttpd has is a debug mode that gives you a stack
> track, and a few other introspection features when a Tcl error
> occurs. Might be worth borrowing the concept.
>
I rely on automated tests to catch this kind of stuff (Now totally off
topic!) Feel free to start another discussion if you are interested in
how we use automated testing in OpenACS.
Dave
--
Dave Bauer
dave@thedesignexperience.org
http://www.thedesignexperience.org/
| |
| Tom Jackson 2006-09-06, 1:11 am |
| In most cases the only thing that I have found helpful for debugging is lots
of data (maybe even a little data). Nothing tests your assumptions more than
lots of examples. I think the main reason is that code is tested with the
same dataset, found to be error free and then the developer moves on. Once
the error is found, it shows up when you are not looking for it, and you have
the added assumption that 'that code works'.
No debugger can ever help too much with this, automated tests can never be
extensive enough to test this because the main issue is that the developer
screwed up and made an assumption. If s/he made it when writing the code, why
wouldn't s/he make the same assumption when writing the test?
The only thing that a debugger has shown to me is that I'm an idiot, that is,
if I could read/write code better, I wouldn't need the debugger.
More important is to avoid the anti-debugger in Tcl: catch. There are only a
few places where this command has any use. If you don't overdose on catch,
the usual AOLserver stacktrace usually locates the error.
tom jackson
On Tuesday 05 September 2006 17:10, Dave Bauer wrote:
> On 9/5/06, John Buckman <john@magnatune.com> wrote:
>
> I rely on automated tests to catch this kind of stuff (Now totally off
> topic!) Feel free to start another discussion if you are interested in
> how we use automated testing in OpenACS.
>
> Dave
| |
| Andrew Piskorski 2006-09-06, 7:11 am |
| On Tue, Sep 05, 2006 at 11:41:40AM -0400, Dossy Shiobara wrote:
> Of course, the more popular languages weren't implemented with
> embeddability (embedibility?) in mind. Tcl is one of the only mature
> languages that can be safely embedded in a multi-threaded application.
Well, I'm sure some one of the eleventy dozen Scheme implementations
out there would be suitable, although I don't know which one. Oh
wait, you said POPULAR languages, nevermind...
AOLserver does already have Standard ML and Objective CAML modules,
which seem to have attracted roughly zero interest from their
respective language communities.
> A global lock? There goes scalability and the benefits of embedding
> Python. (You'd be better off running it in a separate process ala
> FastCGI, AOLserver would gain no performance by embedding it, only
What exactly is the downside of FastCGI? Is it not feasible to
provide 100% of the AOLserver API within the FastCGI constraints?
If so, perhaps it would be easier to add interprocess shared memory to
some trendy non-threadsafe language, than it would be to make the
language implementation threadsafe. One process per interpreter plus
shared memory would definitely work for implementing nsv and ns_cache.
I don't know how much of the AOLserver core would need to be changed
to cope, though.
The above all sounds pretty blue sky of course, but just in case
there's someone out there REALLY interested in embedding a single
threaded interpreter in AOLserver...
> After having said all this, I would like to explore the idea of
> Server-side JavaScript (SSJS):
>
> http://en.wikipedia.org/wiki/Server-side_JavaScript
Hm, that's actually fairly interesting. My impression is that the
Scheme-heads and similar folk also like JavaScript fairly well, btw.
Not having used either one, I'd still guess that XOTcl is probably
more USEFUL, but since it has "Tcl" in its name I guess it doesn't
count. 
> IMHO, this change could put AOLserver back in the beauty pageant.
[shrug] If you want to slingshot AOLserver into much greater
popularity, presumably one good trick is to catch the fancy of some up
and coming development niche or trend and get them to run with it.
Your JavaScript idea seems pretty reasonable as such ideas go, but of
course there's huge amounts of random chance involved.
A simpler first pass approach, which has substantial value in and of
itself, would be to clearly articulate WHY you want to make AOLserver
much more popular than it is. And I don't mean just the fact that you
like it and it would be cool. No, presumably you think AOLserver is
SUPERIOR, and you wish more people appreciate and enjoy that
superiority. So, write a convincing case for why AOLserver is
technically excellent for particular types of uses. A really good
design explication of the core server would probably be a big part of
that.
Ooh, I know, manage to get some job teaching a one semester university
class in advanced server design, and use AOLserver as your code
reference case and test-bed. The notes you'd develop for the class
would probably be an awesome draft for the above. ;)
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
| |
| Andrew Piskorski 2006-09-06, 7:11 am |
| On Tue, Sep 05, 2006 at 10:04:13AM -0700, Tom Jackson wrote:
> However if we could snap our collective fingers and have a multi-language
> AOLserver tomorrow it would instantly be a huge minus. Because it isn't clear
> how you would get two scripting languages to work togeather, you would have
> to choose which one you want to use. You would lose everything written in the
Tom, but that seems silly! Dossy's posited goal is for AOLserver to
become a major cool new platform for Foo programmers, bootstrapping a
whole new, large, and active AOLserver/Foo community. (If it DOESN'T
generate substantial new numbers of AOLserver users, it has failed by
definition.)
If that suceeds, the older, currently existing AOLserver/Tcl community
certainly is not fragmented. Yes, going forward, non-Tcl non-Foo
programmers coming to AOLserver would have to face the question of
which to use, but that seems unlikely to be a major negative.
> other language. The only upside would be that we could have our own
> little language war right here.
"lose everything"? Why? Making AOLserver/Foo really work well would
almost certainly mean building in excellent Tcl/Foo bi-directional
interoperability very early on. Even a major Foo-bigot would still
want that at least for bootstrapping...
And in the "language war" case, at worse probably AOLsever/Foo would
just fork. That seems unlikely to be disastrous for anybody, although
of course anything could happen with human personalities involved.
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
| |
| Andrew Piskorski 2006-09-06, 7:11 am |
| On Tue, Sep 05, 2006 at 01:34:59PM -0400, Rick Gutleber wrote:
> How about The NuffSaid server. Why should you use it? It's good. It's
> got Tcl. 'Nuff said.
Heh, that's pretty good, I like it.
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
| |
| Tom Jackson 2006-09-06, 1:11 pm |
| On Wednesday 06 September 2006 02:33, Andrew Piskorski wrote:
> "lose everything"? Why? Making AOLserver/Foo really work well would
> almost certainly mean building in excellent Tcl/Foo bi-directional
> interoperability very early on. Even a major Foo-bigot would still
> want that at least for bootstrapping...
Hey, why doesn't someone point out where, anywhere, this has been done before?
Then, we don't even need to do this part, because some other group would have
already solved the first problem: they will have identified another scripting
language that can replicate everything that Tcl does, and can speak to Tcl
and allow Tcl to speak to it (and both to C).
All we have to do to make AOLserver more popular is to solve a much more
interesting problem.
In any case, if the new language were to be on par with Tcl, you would have to
replicate everything in the new language. Unless the programmers in the other
language are really behind the times, there must already be an ongoing
web/application server in that language, so we can again look around and find
it. We can introduce the unique AOLserver APIs to this project. But now we
are back to the beginning: AOLserver isn't unique because of the Tcl language
after all, it is unique because of the way it solves a particular problem. If
developers don't like that uniqueness, it doesn't matter what languages are
supported.
tom jackson
| |
| Bas Scheffers 2006-09-06, 1:11 pm |
| On Wednesday, September 6, 2006 16:56, Tom Jackson said:
> it. We can introduce the unique AOLserver APIs to this project. But now we
> are back to the beginning: AOLserver isn't unique because of the Tcl
> language
> after all, it is unique because of the way it solves a particular problem.
> If
> developers don't like that uniqueness, it doesn't matter what languages
> are
> supported.
I agree, I like AOLserver for what it does; a fast multi-threaded server
with DB support better than anyone else's, shared variables better than
anyone else's and scripting support (Tcl libs, re-use of the interpreter,
etc) better than anyone else's. I happen to like Tcl, but the same thing
implemented in PERL or other "toy language" would be equally appealing.
The language is just the glue.
To be honest, the only thing that comes close is Java, in a good server
like Orion. And Java certainly isn't for beginners; apparently even
Greenspun's MIT students can't tame it without programming themselves into
an OO corner...
I really think what's needed is to include a lot more and pretend it is
ours, or at least thoroughly embrace it (TclLib, tdom) and everything is
in one place. See my other post for that.
If we can than create some more "out-of-the-box" modules like an SQL user
repository with API, a framework for making a site multi-lingual (Tcl
msgcat wrapper, really) and the like and praise it for all it is worth,
like other projects do, I think we have a fair chance of popularizing
AOLserver.
Now about the name...
Bas.
| |
| Jeff Hobbs 2006-09-06, 1:11 pm |
| Bas Scheffers wrote:
> If we can than create some more "out-of-the-box" modules like
> an SQL user repository with API, a framework for making a
> site multi-lingual (Tcl msgcat wrapper, really) and the like
> and praise it for all it is worth, like other projects do, I
> think we have a fair chance of popularizing AOLserver.
This is a good point. I've noted to the AOLserver guys before that it could
be rearchitected into something much leaner, meaner and more flexible. It
still has too many remnants of Tcl 7.x architecture days. You could have it
run off a USB key as a single-file executable with an SQLite db now if you
modified things a bit.
Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/
| |
| Jeff Rogers 2006-09-06, 1:11 pm |
| Dossy Shiobara wrote:
> It's about why we end up in situations where we even feel a debugger is
> necessary.
I used to use debuggers much more than I do currently, (probably in
large part because I used to do more C coding), but even though I do 99%
of my debugging without a debugger, that remaining 1% would be far more
painful without the debugger.
There are 2 main places where I find a debugger helpful. One is when I
make stupid mistakes (and if you don't occasionally make stupid mistakes
then I doubt you're actually programming) and the debugger can smack me
upside the head and point out the stupidity ("Oh, it's a fencepost
error!"). The other, more important case is when I am digging into
code that I am not familiar with. In those cases, the debugger can give
a new perspective and let you realize what is going on in the code, at
which point you can ditch the debugger and go back to the code with a
better understanding. Once you are familiar with the code then the
debugger becomes much less useful, but in those initial stages it
greatly speeds the progress.
Linus's rant really rubbed me the wrong way. I thought "considered
harmful" essays went out of vogue a few decades ago. If you'd rather
not use a particular tool fine, but don't imply that people who choose
to use it are somehow inferior.
I thought there was code in AOLserver to support the TclPro debugger -
has that been removed?
-J
| |
| Nathan Folkman 2006-09-06, 1:11 pm |
| dvrsn@DIPHI.COM wrote:
> Dossy Shiobara wrote:
>
>
> I used to use debuggers much more than I do currently, (probably in
> large part because I used to do more C coding), but even though I do
> 99% of my debugging without a debugger, that remaining 1% would be far
> more painful without the debugger.
>
> There are 2 main places where I find a debugger helpful. One is when
> I make stupid mistakes (and if you don't occasionally make stupid
> mistakes then I doubt you're actually programming) and the debugger
> can smack me upside the head and point out the stupidity ("Oh, it's a
> fencepost error!"). The other, more important case is when I am
> digging into code that I am not familiar with. In those cases, the
> debugger can give a new perspective and let you realize what is going
> on in the code, at which point you can ditch the debugger and go back
> to the code with a better understanding. Once you are familiar with
> the code then the debugger becomes much less useful, but in those
> initial stages it greatly speeds the progress.
>
> Linus's rant really rubbed me the wrong way. I thought "considered
> harmful" essays went out of vogue a few decades ago. If you'd rather
> not use a particular tool fine, but don't imply that people who choose
> to use it are somehow inferior.
>
> I thought there was code in AOLserver to support the TclPro debugger -
> has that been removed?
The hooks still exist and it even still works.
Debugging AOLserver pages
* Configure AOLserver to allow debugging, and restart:
ns_section "ns/server/server1/adp"
ns_param enabledebug true
* Download and install the TclDevKit
* Start the debugger:
% tcldebugger &
* Start a new session:
File > New-Project
* Start a new remote session:
Debugging Type > Remote Debugging
* Append the following information to the page you wish to debug:
?debug=<debug>&dhost=<dhost>&dport=<dport>&dprocs=<dprocs>
* AOLserver Dubugging Query Arguments:
debug String. The files you wish to debug. (Example: *, *.adp, foo.inc)
dhost String. The host name the Tcl debugger is listening on. (Example: 127.0.0.1)
dport Integer. The port the Tcl debugger is listening on. (Example: 2576)
dprocs String. Procedures to instrument. (Example: ns*, foo_something)
* Example:
http://foo.com:8000/test.adp?debug=....0.1&dport=2576 <http://foo.com:8000/test.adp?debug=....0.1&dport=2576>
Hope that helps!
- n
>
> -J
>
>
> --
> 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.
| |
| Dossy Shiobara 2006-09-06, 7:11 pm |
| On 2006.09.06, Jeff Rogers <dvrsn@DIPHI.COM> wrote:
> There are 2 main places where I find a debugger helpful. One is when I
> make stupid mistakes (and if you don't occasionally make stupid mistakes
> then I doubt you're actually programming) and the debugger can smack me
> upside the head and point out the stupidity ("Oh, it's a fencepost
> error!").
Automated tests should really eliminate this class of bugs, eliminating
the need for the debugger.
> The other, more important case is when I am digging into code that I
> am not familiar with.
Again, automated tests provide much more value here than a debugger. I
can look at code, "guess" as to what it's supposed to do, write an
automated test that asserts my understanding, and if it fails, then I
know my understanding was wrong. If it passes, then I understood that
piece correctly.
The upside here is once I've built up the tests, I can start to make
changes to the code and so long as I don't make any of the previous
tests fail, I know I've preserved the functionality that I've written
tests for.
Writing the tests once and being able to share and reuse them is worth
much, much more than one throw-away session in a debugger. The tests
will continue to provide value as long as they're relevant. The session
in the debugger only provides the user of the debugger insight (not the
whole team, who could read and run the tests).
> Linus's rant really rubbed me the wrong way. I thought "considered
> harmful" essays went out of vogue a few decades ago. If you'd rather
> not use a particular tool fine, but don't imply that people who choose
> to use it are somehow inferior.
I think Linus's rant was on-the-mark: if you feel the need for the
debugger, you're acknowledging a lack of sufficient understanding.
Linus's argument, as I understand it, says that "yes, a debugger is one
way of increasing your understanding, but not the best way, and
definitely not a way I personally intend to support in the Linux
kernel."
> I thought there was code in AOLserver to support the TclPro debugger -
> has that been removed?
Not that I'm aware of, but it also may not have been used or exercised
in a very long time. Or, if it has, I haven't heard of it.
-- 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)
| |
| Rusty Brooks 2006-09-06, 7:11 pm |
| It's funny... I know we're all experienced developers and that
therefore all of our viewpoints have validity, but to me debugger > test
cases. I am really doubting you are going to have enough test cases to
cover all conceivable reasonable inputs.
This is not meant to be a barb, but, for example, do you have a
test-case that examines what happens if someone ns_returnredirects and
then doesn't do an ns_adp_abort before the end of the page? AOLServer
contains a programming language and an extensive API, MANY of the
commands have unexpected interactions that you don't even know about yet.
I learned a valuable lesson a few years ago. A co-worker of mine, whos
opinions I did and do respect, held opposite viewpoints as me on some
programming concepts. We didn't work together for a few years, and then
we did again, and BOTH of us had reversed our opinions and now were
equally fervent in the opposite direction. This was enlightening to me,
because it revealed that people can hold opposite viewpoints of you and
still be right. Yes, I was rather young when this happened ;)
Rusty
Dossy Shiobara wrote:
> On 2006.09.06, Jeff Rogers <dvrsn@DIPHI.COM> wrote:
>
> Automated tests should really eliminate this class of bugs, eliminating
> the need for the debugger.
>
>
> Again, automated tests provide much more value here than a debugger. I
> can look at code, "guess" as to what it's supposed to do, write an
> automated test that asserts my understanding, and if it fails, then I
> know my understanding was wrong. If it passes, then I understood that
> piece correctly.
>
> The upside here is once I've built up the tests, I can start to make
> changes to the code and so long as I don't make any of the previous
> tests fail, I know I've preserved the functionality that I've written
> tests for.
>
> Writing the tests once and being able to share and reuse them is worth
> much, much more than one throw-away session in a debugger. The tests
> will continue to provide value as long as they're relevant. The session
> in the debugger only provides the user of the debugger insight (not the
> whole team, who could read and run the tests).
>
>
> I think Linus's rant was on-the-mark: if you feel the need for the
> debugger, you're acknowledging a lack of sufficient understanding.
> Linus's argument, as I understand it, says that "yes, a debugger is one
> way of increasing your understanding, but not the best way, and
> definitely not a way I personally intend to support in the Linux
> kernel."
>
>
> Not that I'm aware of, but it also may not have been used or exercised
> in a very long time. Or, if it has, I haven't heard of it.
>
> -- Dossy
>
| |
| Daniël Mantione 2006-09-06, 7:11 pm |
| | |
| Rick Gutleber 2006-09-06, 7:11 pm |
| Although not relevant here, debuggers are practically mandatory when you
are using a closed-source system. Documentation being what it is
(AOLServer is hardly the exception), sometimes it's the only way to know
what's going on.
As much as it would please, however, me to be able to step through Tcl
code, I think Dossy is correct. You really can live without one.
Dossy Shiobara wrote:
> On 2006.09.06, Jeff Rogers <dvrsn@DIPHI.COM> wrote:
>
>
> Automated tests should really eliminate this class of bugs, eliminating
> the need for the debugger.
>
>
>
> Again, automated tests provide much more value here than a debugger. I
> can look at code, "guess" as to what it's supposed to do, write an
> automated test that asserts my understanding, and if it fails, then I
> know my understanding was wrong. If it passes, then I understood that
> piece correctly.
>
> The upside here is once I've built up the tests, I can start to make
> changes to the code and so long as I don't make any of the previous
> tests fail, I know I've preserved the functionality that I've written
> tests for.
>
> Writing the tests once and being able to share and reuse them is worth
> much, much more than one throw-away session in a debugger. The tests
> will continue to provide value as long as they're relevant. The session
> in the debugger only provides the user of the debugger insight (not the
> whole team, who could read and run the tests).
>
>
>
> I think Linus's rant was on-the-mark: if you feel the need for the
> debugger, you're acknowledging a lack of sufficient understanding.
> Linus's argument, as I understand it, says that "yes, a debugger is one
> way of increasing your understanding, but not the best way, and
> definitely not a way I personally intend to support in the Linux
> kernel."
>
>
>
> Not that I'm aware of, but it also may not have been used or exercised
> in a very long time. Or, if it has, I haven't heard of it.
>
> -- Dossy
>
>
--
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.
| |
| Dossy Shiobara 2006-09-06, 7:11 pm |
| On 2006.09.06, Dani=EBl Mantione <daniel.mantione@FREEPASCAL.ORG> wrote:
> Ok, who here in this mailinglist doesn't use ns_log debugging? My pages=
=20
> are always full of ns_log statements, and there is a tail running in=20
> another window to be able to immedeately see the results.
Tracing program execution is not the same as debugging (ad-hoc program
state inspection).
I don't think Linus would ever seriously suggest removing printk() from
the Linux kernel and corresponding klogd.
-- Dossy
--=20
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)
| |
|
| |