Forum OpenACS Q&A: Response to nstcl

76: Response to nstcl (response to 1)
Posted by Michael A. Cleverly on
I didn't design nstcl with any intent to replace AOLserver (now or in the future). I wrote nstcl because I like to use the AOLserver/(O)ACS-idioms in the work I do (both professionaly and just for fun) in Tcl/Tk (but outside of AOLserver).  It's allowed me to be much more productive in areas outside of web development.  Even when a script doesn't do anything database related, just being able to use ad_proc in tclsh is a big win.

The first version of nstcl came about because I found the pgtclsh database extensions interface to be so much more painful than the AOLserver database api's that I'd come to know & love over the previous three years, so I created wrapper procs to emulate the AOLserver API.  From there it grew to support Solid, and then Oracle, plus other things like ns_sendmail, ns_hrefs, etc.

With the latest release came templating, a general code cleanup, actual documentation (I was getting sick of Kriston redesigning the site and breaking all the existing link/URLs every couple of months), a test suite, and more supported database extensions.

I don't have any experience using a threaded version of tclsh, so I can't even begin to comment on the thread safety of nstcl.  In general I think it should be no more and no less than any other library of pure-Tcl code.  Another question would be the underlying thread-safety of the database extensions themselves, I suppose.  IIRC Oratcl 4.0 claims to be thread-safe now, whereas previous versions weren't.  I have no idea about pgtclsh and the others.

John emailed me and asked if I saw any obvious reasons that would completely rule out it's use with FastCGI.  I don't see any issues that are insurmountable.

Obviously nstcl would need all the AOLserver API's related to HTTP & HTTPS requests/connection handling.  My working version of nstcl 1.1  adds some additional non-connection oriented commands: the ns_schedule_proc and ns_config/ns_param set of commands, for instance.

I hope that anyone who decides to persue this path would _fully realize_ the speed difference between a C implementation (AOLserver) and anything written in pure Tcl (nstcl).  That said, however, for low-end/low-volume sites, I imagine speed wouldn't be an issue.

BTW, there's at least one area where nstcl already outshines AOLserver/(O)ACS: migrating data from two different types of databases (Oracle to Postgres, for example), because nstcl's database api doesn't force you to fall back on the AOLserver ns_db api for the second database. :^)