So in actual fact I'd like to see us resist converting things to TCL for their own sake and leave it as a 'only when its *really* justified'....
Unfortunately the packaging issue is extremely real for many people. Making our core technology dependent on java would be a mistake if that can't be solved. SOAP's too important, if WebDAV gets blended into our CMS efforts (which sounds like a good idea) it too will be too important. If we have such a CMS solution we'll want people to be able to download it and fire it up, right out of the box, not dick around with configuring Java pieces. This isn't a matter of "rewriting for the sake of rewriting".
On the other hand offering the capability to blend easily with Java in order to integrate with less critical bits of technology is really great, yes indeed.
As far as programming out AOLserver dependencies and moving to a pure Tcl-based solution ... why do we want to move to a technologically inferior platform? There's no way we're going to match the AOL folks in building an independent platform that delivers high performance.
Running AOLserver natively under windows isn't an impossibility, there's already an OpenACS site in Ireland that runs natively under windows. Jamie plans to bundle it up when AOLserver 4.0 comes out, I believe. If he doesn't have time then surely the time involved in getting this packaged won't be huge.
The problem then is writing a MSSQL driver for AOLserver. Since MSSQL is based on Sybase and since the AOLserver Sybase driver is essentially an ODBC driver, I don't think this should be terribly difficult either.
And porting the toolkit to another RDBMS is not a trivial undertaking. The work I describe above will be a piddling fraction of a total porting effort.
AOLserver is the most solid piece of technology in our platform, we shouldn't be in such a rush to dump it.
