The documentation may be a little dated, but, we're on 2.3.3 and developed
our web site over a 4 year period with no access to source - only the docs.
There have been a few obscure server bugs where access to the source
would have been very helpful, but the "read the source to understand"
mentality is not necessary to develop with AOLServer, IMO.
Stuff like caching web pages to avoid DB calls - we do that in 5-10
lines of TCL, either caching in shared variables or on disk. Very simple:
Memory:
ns_share cache
-- compute cache tag for this request (maybe using URL, maybe something else)
if {[info exists cache($cachetag)] && $cache($cachetag,mtime) > [ns_time]-600} {
ns_return 200 text/html $cache($cachetag)
return
}
-- generate HTML
set cache($cachetag) $html
set cache($cachetag,mtime) [ns_time]
ns_return 200 text/html $html
Disk cache:
-- compute cache tag for this request (maybe using URL, maybe something else)
set cachefile $cachedir/$cachetag
if {[file exists $cachefile] && [file mtime $cachefile] > [ns_time]-600} {
ns_returnfile 200 text/html $cachefile
return
}
-- generate HTML
set tempfile $cachefile.[ns_time]
set fd [open $tempfile w]
puts $fd $html
close $fd
rl_mv $tempfile $cachefile (C module: "mv" command)
ns_return 200 text/html $html
I agree that the model of using layers of "black boxes" will not work
very well with web sites because of scalability issues. If there is a
hot spot on your web site, it can cause HUGE loading problems for the
entire site. If it is in the middle layers of a bunch of black box
software, how do you fix it? Adding gobs of servers is always an
option, but then it changes a one-time development problem into an
ongoing system administration problem.
Jim
>
> Many thanks to all those who took the time to reply to my question.
>
> I am hugely impressed with AOLServer and plan to do some serious evaluation of
> the product and the associated development process with my colleague over the
> next months.
>
> On balance - at this point in time I am leaning more toward AOLServer + TCL +
> Oracle than Apache/Tomcat/Javabeans etc.
>
> I feel much more comfortable about the scalability of the AOLServer model because
> bottlenecks are much easier to find and resolve in the absence of the
> multi-layered complexity inherent in the java based solutions. JVM's terrify me
> more than anything else on earth when they are let loose on my computers (except
> perhaps my 4 year old son)!
>
> During the development cycle you can only imagine the pleasure I experienced
> making a change to a bit of TCL, saving the file, and refreshing the page in the
> browser to see the effect! While using Tomcat we invariably had to restart
> tomcat to be sure of seeing changes to JSP pages. I am not sure but I believe
> later versions of tomcat require Apache to be restarted also.
>
> I have noticed some comments about the documentation - Personally, what I have
> seen so far looks good, I can buy books on TCL and I can read the source.
>
> Thanks again to all - especially those at AOL who work on the core product and
> are so willing to share the fruits of their labours.
>
> Alan Wright
>
