See GSOC2010:OpenACS Abstraction Layer for an attempt at this.
Wub is a showcase technology for Tcl with its speed and use of coroutines. OpenACS is also a Tcl success story, but it is limited on one end by AOLServer and on the other by dependence on Oracle/PostgreSQL. The goal of this project would be to enable an alternative (nearly) pure-Tcl OpenACS stack and replace the specific database dependencies with TDBC, which would ease install and deployment, and enable use of OpenACS modules in a wider range of contexts. Project steps would consist of:
These steps could comprise one or several individual student projects.
Benefit for student: get experience with web technology and performance testing, high-demand database technology, threading.
Benefit for community: leverage strong but under-utilized code base with cutting-edge new Tcl innovations, and vice versa. Liberate OpenACS code to be used in new contexts. Make it easier to create and deploy new custom OpenACS configurations.
The nstcl project may be relevant for this. Also, a similar partially-executed project is described at http://www.jsequeira.com/projects/portable.nsd/
CMcC asides that since TDBC requires tcl8.6, one means of satisfying the community benefits of this project would be to treat it as a software archeology and restoration projecct: take those bits of OpenACS which work well, and rewrite them to (1) provide a more abstract interface to the underlying web facilities (much as TDBC provides an abstract DB layer), (2) use tcl8.6 facilities (I'm thinking dict, here for representing data.) The first would liberate the useful facilities for broader use, the second would probably make the code cleaner than it is now. It's the same project, really, but turned inside-out.
sisusimple thinks another way round: is it possible to make a library for TCL of AOLserver? Benefit: mature http server, easier integration with other TCL code.
SEH: Wub is pure Tcl. AOLServer is a mix of Tcl and C, and thus presents issues of portability, maintainability and deployability. One of the goals of this project would be to make OpenACS more portable and deployable. It might be interesting to see if one could turn AOLServer into a stubs-enabled loadable library. But I think that would be a separate project.
tclbliss This is just my opinion, but I would completely stay away from re-creating OpenACS. I have looked at it many times over the years and the project is stagnating. It is too complicated and I have never had a single time where I installed it and it ran without any errors or problems. My main reason to stay away from it not just that it is too complicated but that it is unnecessarily too complicated. I believe that things can be done and should be in a much simpler ways than the way OpenACS does it. It would be much easier and better to create something new from the scratch than to re-create OpenACS. You would also have a problem with converting Postgres/Oracle databases to generic TDBC, because OpenACS database code is very Postgress/Oracle specific. This is not some generic SQL you can run on any database engine. But again, this is just my opinion, your mileage might vary. At least think it over carefully before starting this project whether you can complete it. Don't waste your life on something that will not be finished (during your lifetime) ;).