Re: [AOLSERVER] AOLserver's documentation woes and its future
Daniël: In real-time or high performance applications, the very act of loading the code into a debugger is going to affect, or perhaps completely distort, the performance of the program and quite possibly alter or mask the very problems you are trying to fix. A well-placed print statement won't. I've read about studies in the past that software developers that were not given access to computers until their code was written we actually more productive than those who could go through innumerable code-run-fix iterations. Of course, in the real world, that doesn't work because in the real world, you are interacting with other software that you either can't know the complete details of, or don't have control over, or more likely, both. Take Windows programming for instance (I always go back to that since I'd been doing for 15 years). The low-level documentation, while generally pretty good, is never complete and of course you will often have to reverse engineer actual behavior and bugs. This is often much more difficult or even impossible without a debugger. If, however, you have complete control over the entire environment (or your interfaces to other pieces are very well-defined and constrained), then you should be able to take a more deterministic approach to fixing problems. You have the code, you should know what it does, debugging should mostly (or totally, like you point out) be done by looking at the code and figuring out what's wrong. Of course, in the case of multi-threaded code, it's quite possible that you simply can't understand all the interactions because multithreaded development can be very complex. Thus the reasonable allowance for print statements. So I don't think Linus is being a hypocrite, nor do I think Dossy is being a Luddite. Different environments require different tools. Like I said, a debugger would be great... I was really bemoaning the fact I didn't have one when I started Tcl coding a few months ago, now it really doesn't bother me. The world of AOLServer, it seems, is divided into two kinds of people. Those who are willing to embrace Tcl and those who won't (or can't). I had not realized the incredible technological barriers (mostly dealing with thread-safety) that prevent AOLServer easily supporting other, more popular, languages. While the AOLServer project should do everything it can to maximize interoperability with other platforms or applications, I guess the real focus should then be to provide as complete a set of tools and examples as possible. A colleague of mine was raving about how easy it was to set up a simple, but really nice-looking photo gallery using (IIRC) Django. That's great. AOLServer devotees should be able to do the same exact thing. Unfortunately in this day and age, framework libraries are a necessity... we shouldn't be reinventing the same wheels, but in my experience, most libraries that do anything significant can be as hard as developing the features from scratch. _This_ is the problem that almost no one has really solved. Of course, this is just my 2c. Outside of supporting ADP stuff at AOL, I haven't had any experience with AOLServer... but in that brief time, I've become a convert. In my experience, a good development environment has an elegance that strikes you at a gut level, and this one does that for me. Rick Daniël Mantione wrote: Op Wed, 6 Sep 2006, schreef Dossy Shiobara: On 2006.09.06, Rick Gutleber <[EMAIL PROTECTED]> wrote: 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. I think the point here is, if you force yourself to live without one, it demands that you become a better programmer. Either that, or spend a lot of time chasing down stupid bugs without the debugger. Just because a debugger reduces the time you spend chasing down stupid bugs, it doesn't force you to become a better programmer. When you have a debugger, what's your incentive for becoming a better programmer? Where's the "pain" that you work hard to avoid? That is just as stupid a comment as that word processors are bad; you should use typing machines instead because with the typing machine you learn to avoid typing errors. Facts are that for example data typists (people who cannot afford to make typing errors) have abandonned typing machines decades ago. People who have learned to do calculating with slide rules instead of just pen and paper claim to be able to understand the process much better than the pen and paper people. They say that because they see how the slide rule gets to the answer they have a better insight in calculations. It is the same with a debugger. A programmer who uses a debugger sees his algorithm actually working and will get more insight in it. Debuggers result in programmers that understand their programs better because they have seen their algortihms a
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.07, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > Tracing program execution is not the same as debugging (ad-hoc program > > state inspection). > > Huh? What do you think the step-into and step-over buttons of a debugger > are being used for? Tracing the program execution perhaps? I can trace execution of a program in a production environment (think: turn on logging) but I certainly can't halt the system and step through it with a debugger. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Op Wed, 6 Sep 2006, schreef Dossy Shiobara: > On 2006.09.06, Tom Jackson <[EMAIL PROTECTED]> wrote: > > Anyway, the code that is causing the segfault is very likely to be the > > type of thing that you could never write a test for. And writing a > > test right now, just to make sure it doesn't happen again seems > > equally impossible. > > Of course you can write a test for it. Create an ADP page that issues a > ns_returnredirect, starts a server with a stripped down test config, and > then hit the server (wget, curl, Tcl http package, etc.) and verify that > it returned the correct response *and* didn't exit with a signal. "Testing can be used to prove the existance of bugs, but is totally useless for proving their absence" -- Edsger W. Dijkstra. In other words, to write bug free code, you cannot rely on testing. You have to understand what happens. Now, Dijkstra propably didn't use debuggers, because he didn't like iterative design and instead designed his algorithms on paper, only using a computer after he had proven them to be correct. Daniël -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
To begin, let's not say I'm a fan of debuggers, nor am I an enemy of test cases. I think they both have their place. I don't think that avoiding an available tool is a necessarily a good idea. Further, your claim below is somewhat silly, I think, unless you think that all large projects, AOLServer included, is overly complex and requires refactoring. I would suggest that it's strictly impossible to make a complete set of test cases for AOLServer as a software project. At best you can trail behind the found bugs, making test cases for each of them, and avoiding them cropping up again, and make a set of tests that test the *basic* functionality of the API commands.. If you don't think this is true then man do I ever have a bet I'd like to propose. I know that you're talking about the need for a debugger to debug web applications, which you probably consider less complex than a project like AOLServer, and I do too for the most part, but even web apps and the like can get too large and complex to rely on test cases and ns_log alone. Rusty Dossy Shiobara wrote: On 2006.09.06, Rusty Brooks <[EMAIL PROTECTED]> wrote: 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. If your code under test is capable of doing so many things that you can't create a reasonable list of testable items, then I firmly assert that your design is overly complex and requires simplification and refactoring. Some truths I've discovered along the way: * Good code is easy to test. * It's really hard to write good code. * Most code isn't easy to test, because it's not that good. Then, if you drink the test-driven development Kool-Aid, you start to discover: * Writing tests first nudges you in the direction of better code. 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? We should have a test case for this, yes. Unfortunately, AOLserver lacks reasonable automated tests, at the moment. AOLServer contains a programming language and an extensive API, MANY of the commands have unexpected interactions that you don't even know about yet. This is because much of the functionality lacks tests. This is something we definitely need to address. -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Op Wed, 6 Sep 2006, schreef Dossy Shiobara: > On 2006.09.06, Rick Gutleber <[EMAIL PROTECTED]> wrote: > > 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. > > I think the point here is, if you force yourself to live without one, it > demands that you become a better programmer. Either that, or spend a > lot of time chasing down stupid bugs without the debugger. > > Just because a debugger reduces the time you spend chasing down stupid > bugs, it doesn't force you to become a better programmer. > > When you have a debugger, what's your incentive for becoming a better > programmer? Where's the "pain" that you work hard to avoid? That is just as stupid a comment as that word processors are bad; you should use typing machines instead because with the typing machine you learn to avoid typing errors. Facts are that for example data typists (people who cannot afford to make typing errors) have abandonned typing machines decades ago. People who have learned to do calculating with slide rules instead of just pen and paper claim to be able to understand the process much better than the pen and paper people. They say that because they see how the slide rule gets to the answer they have a better insight in calculations. It is the same with a debugger. A programmer who uses a debugger sees his algorithm actually working and will get more insight in it. Debuggers result in programmers that understand their programs better because they have seen their algortihms actually work. Because they understand them, they can make them better. > Remembering and carefully avoiding past mistakes (why bother, when you > can just root them out in the debugger)? Improving your fundamental > design repertoire to eliminate known bad decisions (why bother, the > debugger will let you finagle your way through even the worst of rats > nests)? > Perhaps that's the wisdom that Linus was trying to impart, here. Linus has been rejecting source code management tools for years because "real programmers don't need them". When he finally used one he found he became two, three times more productive merging patches. He's a smart guy, but at the same time he is a fool. Note also that Linus does use a debugger, in the sense of attaching gdb to a running kernel. You can't debug the kernel, but you can inspect its variables and data structures. Daniël -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Op Wed, 6 Sep 2006, schreef Dossy Shiobara: > On 2006.09.06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > Ok, who here in this mailinglist doesn't use ns_log debugging? My pages > > are always full of ns_log statements, and there is a tail running in > > another window to be able to immedeately see the results. > > Tracing program execution is not the same as debugging (ad-hoc program > state inspection). Huh? What do you think the step-into and step-over buttons of a debugger are being used for? Tracing the program execution perhaps? > I don't think Linus would ever seriously suggest removing printk() from > the Linux kernel and corresponding klogd. Exactly, so he is a bit hypocrite, as he does use a debugger, a primitive one, and rejects more advanced debuggers that would make him more productive. Daniël -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Dossy Shiobara wrote: On 2006.09.06, Rick Gutleber <[EMAIL PROTECTED]> wrote: 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. I think the point here is, if you force yourself to live without one, it demands that you become a better programmer. Either that, or spend a lot of time chasing down stupid bugs without the debugger. Just because a debugger reduces the time you spend chasing down stupid bugs, it doesn't force you to become a better programmer. When you have a debugger, what's your incentive for becoming a better programmer? Where's the "pain" that you work hard to avoid? Remembering and carefully avoiding past mistakes (why bother, when you can just root them out in the debugger)? Improving your fundamental design repertoire to eliminate known bad decisions (why bother, the debugger will let you finagle your way through even the worst of rats nests)? Perhaps that's the wisdom that Linus was trying to impart, here. I for one don't think that programming should be painful; I prefer it to be enjoyable (honestly, if I found it painful I'd find a different line of work). Finding bugs with a debugger is plenty painful anyway, and wanting to improve myself as a programmer is enough of a motivation to be a better programmer and not make the same mistakes again. -J -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.06, Tom Jackson <[EMAIL PROTECTED]> wrote: > Anyway, the code that is causing the segfault is very likely to be the > type of thing that you could never write a test for. And writing a > test right now, just to make sure it doesn't happen again seems > equally impossible. Of course you can write a test for it. Create an ADP page that issues a ns_returnredirect, starts a server with a stripped down test config, and then hit the server (wget, curl, Tcl http package, etc.) and verify that it returned the correct response *and* didn't exit with a signal. > Also, the bug I (re)fixed this weekend would never be > testablebut If you can reproduce the bug, it's testable. If you can't reproduce it, I assert that it's equally hard to fix as it is to test for. If you understand what the problem is enough to fix it, you should be able to elicit the condition through a test. Otherwise: how do you verify that your fix actually, well, fixed it, if you can't manually test the before-and-after conditions? And, if you can manually test it ... why can't you automate it? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.06, Rick Gutleber <[EMAIL PROTECTED]> wrote: > 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. I think the point here is, if you force yourself to live without one, it demands that you become a better programmer. Either that, or spend a lot of time chasing down stupid bugs without the debugger. Just because a debugger reduces the time you spend chasing down stupid bugs, it doesn't force you to become a better programmer. When you have a debugger, what's your incentive for becoming a better programmer? Where's the "pain" that you work hard to avoid? Remembering and carefully avoiding past mistakes (why bother, when you can just root them out in the debugger)? Improving your fundamental design repertoire to eliminate known bad decisions (why bother, the debugger will let you finagle your way through even the worst of rats nests)? Perhaps that's the wisdom that Linus was trying to impart, here. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.06, Rusty Brooks <[EMAIL PROTECTED]> wrote: > 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. If your code under test is capable of doing so many things that you can't create a reasonable list of testable items, then I firmly assert that your design is overly complex and requires simplification and refactoring. Some truths I've discovered along the way: * Good code is easy to test. * It's really hard to write good code. * Most code isn't easy to test, because it's not that good. Then, if you drink the test-driven development Kool-Aid, you start to discover: * Writing tests first nudges you in the direction of better code. > 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? We should have a test case for this, yes. Unfortunately, AOLserver lacks reasonable automated tests, at the moment. > AOLServer contains a programming language and an extensive API, MANY > of the commands have unexpected interactions that you don't even know > about yet. This is because much of the functionality lacks tests. This is something we definitely need to address. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On Wednesday 06 September 2006 14:28, Rusty Brooks wrote: > 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. > This is a purely theortical situation. It assumes that you know what you are going to program ahead of time. This is almost like thinking that even a thorough book outline would replace the book, and even just spell checking the outline is good enough. Tests only cover what you expect to go wrong. And somehow they also assume that you can write better tests than actual code. Anyway, the code that is causing the segfault is very likely to be the type of thing that you could never write a test for. And writing a test right now, just to make sure it doesn't happen again seems equally impossible. Also, the bug I (re)fixed this weekend would never be testablebut One thing I did was to put in some Ns_Log statements so that I now know what internal redirects are being registered, or if the code tried and failed, why did it fail. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.06, Daniël Mantione <[EMAIL PROTECTED]> wrote: > Ok, who here in this mailinglist doesn't use ns_log debugging? My pages > are always full of ns_log statements, and there is a tail running in > 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 -- Dossy Shiobara | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> 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
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Op Wed, 6 Sep 2006, schreef Dossy Shiobara: > > 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." Ok, who here in this mailinglist doesn't use ns_log debugging? My pages are always full of ns_log statements, and there is a tail running in another window to be able to immedeately see the results. Sure, it works, but a good debugger can make this laborious task of manually adding ns_log commands totally obsolete. It is just the same as all other kinds of automation and has nothing to do with "lack of sufficient understanding". Daniël -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> 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
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.06, Jeff Rogers <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
[EMAIL PROTECTED] wrote:
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?
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=&dhost=&dport=&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=*&dhost=127.0.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
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> 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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 9/5/06, John Buckman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.thedesignexperience.org/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On Sep 5, 2006, at 6:00 PM, Jeff Hobbs wrote: 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 agree, BUT feel free to express my vote for a Mac OSX version of Tcl Dev Kit. 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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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:[EMAIL PROTECTED] 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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 9/5/06, Titi Ala'ilima <[EMAIL PROTECTED]> wrote: Rick Gutleber wrote: > > 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. 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. Don't forget to look at XoTcl which runs just fine in AOLserver. http://media.wu-wien.ac.at/ -- Dave Bauer [EMAIL PROTECTED] http://www.solutiongrove.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.05, Titi Ala'ilima <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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:[EMAIL PROTECTED] 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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
[EMAIL PROTECTED] wrote: 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) 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.05, Janine Sisk <[EMAIL PROTECTED]> wrote: > 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? 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 | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.05, Jeff Hobbs <[EMAIL PROTECTED]> 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/linus-im-a-bastard-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 | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Rick Gutleber wrote: > > 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. 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. > > 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. My question is aimed at finding out who would have the resources and motivation to subsidize developers? -T. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 > > 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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 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! -Titi -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
> 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,
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
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
[EMAIL PROTECTED] wrote: (Apologies for the long email ahead ... but, I think it's worth a quick read.) On 2006.09.05, Rick Gutleber <[EMAIL PROTECTED]> 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-dev&m=108736540021355&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/developers/06/07/28/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
Re: [AOLSERVER] AOLserver's documentation woes and its future
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
(Apologies for the long email ahead ... but, I think it's worth a quick read.) On 2006.09.05, Rick Gutleber <[EMAIL PROTECTED]> 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-dev&m=108736540021355&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/developers/06/07/28/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 enhancem
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> 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
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
On 2006.09.05, Bas Scheffers <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | 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 <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
Op Fri, 1 Sep 2006, schreef Dossy Shiobara: > 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. A successfull open source project needs a few ingredients. I'll compare with my own project, Free Pascal Compiler: * People who push the development. For FPC this means that the core team does the dirty work of advancing register allocations, optimizations and ports to new processors etc. * A community that helps with the development. For example, we ported FPC to the ARM processor. This is pushing development. Once this was done, people jumped out of bushes from all directions to apply it, now we have Free Pascal for Windows CE, Free Pascal for Nintendo Game Boy, all done by people from community. * Good documentation. The importance of documentation is often underestimated, but it is one of the main things potential users look at when investigating wether something can do what they need. * Low bureaucracy to contribute. Wikis are succesfully used here, but the real challenge is low bureaucracy patch contributions. * Self-help support facilties, i.e. FAQs, user mailing-lists, forums. Now lets look at AOLserver for these ingredients: * People who push development. Well, AOLserver is not a intense developed project, but there is active development. The 4.5 release is a big improvement over 4.0, and so is 4.0 over 3.5. * A community that helps with the development. The community rarely contributed patches, but writes modules and does it well, giving AOLserver an interresting collection of modules. * Good documentation The documentation documents a rather complete set of the API and configuration. However, the accessibility and readability is bad, the layout often sucks. * Low bureaucracy to contribute I once contributed a patch. It was ignored, despite positive comments. While obviously there are no bad intentions, this sucks. Users can contribute to the documentation. * Self-help support facilties. Well, we have this mailinglist, but other than that, there aren't much facilities. Some information that many people want to know, for example how to run Apache and AOLserver on 1 IP-address cannot be found at the moment. It has to be said that things were better during the 3.0 period. The web site was better, interesting knowledge could be found in the AOLserver community forums. So, AOLserver has a lot of ingredients for being a successfull open source project, but some are lacking. Improving the project might help as much as promoting it. Daniël -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver's documentation woes and its future
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 everyon
