Forum OpenACS Q&A: Response to nsjava staus

64: Response to nsjava staus (response to 1)
Posted by John Sequeira on

I think the lame EULA applied to dev tools.  I used emacs and perl/dbi to do the kernel port,  so I think it's safe :-).
I'd be happy to write something up for oASJ at some point.


Database and webservers are peculiar beasts.  Organizations would much prefer to not support many of them.  Most of the serious environments I've coded in have centralized monitoring apparutus (HP OpenView, CA's TNG, NetIQ, etc).  It's a big deal in $$$ and time to add a new set of infrastructure that has to be monitored and patched.  Way more if you're looking at some type of common fault tolerant architecture (w/replication, failover) in the db tier.  Doing that several different ways gets complicated and expensive quickly.

I'm not saying MSSQL is a better database,  it's just better if you've already bought it :-)  Anyone with a big investment in MSSQL behind their web site would prefer new code and data sit side-by-side,  and not have a new set of integration issues to contend with.  There are a lot of sites like this,  I would argue more than any other platform right now ( I think Oracle wins in $$$, not installed instances,  + MS has a free version of SQL Server )

OpenACS is the best thing out there for a stand-alone CMS or community-based corporate site.  But it has the potential to do a lot more,  if it could leverage the hooks developed by the vastly larger TCL community in terms of data access etc.

As Don pointed out,  the db driver and apache stuff *can* be done,  but my point is that it *has* been done,  and it's never really gotten critical community mass to be supported.  We can keep trying,  a new nsd module,  a new AOLServer port, as Don suggests.  These are useful endeavors,  and will probably succeed for awhile,  but ....  It seems just plain unnecessary to continually require people to fire up their c compilers and keep current with their respective projects external dependencies (apache, sql server, iis, Windows + openacs and aolserver)  over and over again.  I think FastCGI gets us out of this rut.


THANK YOU!  That kind of feedback was what I was looking for.

FastCGI supports filters, and multiple persistent interpreter instances,  each of which can support a persistent connection.  I *think* that minimizes the threading and pooling issues.

ns_conn shared data is my biggest concern,  but I think FastCGI's session affinity might address it.  In essense,  you're getting the same architecture as a web farm (multiple discrete load-balanced instances),  but at the interpreter level instead of the web listener level.  If you have a performance problem,  you just add more interpreters,  potentially on other machines.  This means that you take a hit having in-memory multiple caches,  but since it's the same issues w/a web farm it doesn't seem too bad to me.

I think ns_cache (is that required?), other required modules (?), config files and scheduling stuff would likely remain platform specific.  That doesn't seem like too big a deal.