Forum OpenACS Development: TCLlib

Tcllib has a lot of useful function which we are currently not harnessing, but which we will need the moment we commit the tclsoap package for openacs (which works with tdom instead of tcldom).

Now, my proposal would be to take TCLlib and just add it as an OpenACS package like acs-tcl as no compiling is needed (to my knowledge, but might be wrong).

The benefit would be that the APM can decide whether TCLlib has to be included or not and you can easily install it without the need to install yet another package for AOLserver.

What do you think, am I missing something here?

I would prefer that rather than include something we don't need to change at all, we provide a tarball of the "extras" (if we do anything). One of the problems is that we do a bad job of keeping things up to date and putting it in CVS is a big part of that -- the base64 and mime stuff we pulled is quite out of date relative to tcllib as was htmlarea and pretty much any other "external package" we have pulled in.

The reasons for AOLserver, Postgres et al not being part of an OpenACS checkout: It won't work, as you need to compile them (and they need to be there *before* you can access the apm).

But I agree, our track record for external software inclusion is not very encouraging, so maybe we should add this to the installer and the installation instructions.

Is there a way for the APM to not display packages for installation that have a TCL package require dependency ?

Talking about HTMLarea, I don't suppose we can retrieve this from a different place with the installer?

One more thing to note though. Everyone would have to keep their installations up to date on all the seperate packages and until we have the installers working, the installation would get even more complex.

This is in contrast to one person updating the ACS package and everyone just making an upgrade from repository or CVS, which is something you normally do on a regular basis anyway.

This said, I'd commit myself to update a TCLlib package every time a new release of TCLlib is available.

I see no reason whatsoever to make Tcllib an OpenACS package, and most certainly no reason to de-facto fork it by importing it into OpenACS CVS. Now that OpenACS is on AOLserver 4.x (rather than 3.x), if you want to use Tcllib with OpenACS, only three things are required:

1. Install stock Tcllib, just like you install stock Tcl.
2. "package require tcllib"
3. As Jon G. brings up, understand what parts of Tcllib make not-true-under-AOLserver assumptions about the Tcl runtime environment, and avoid all use of those parts. (Probably add some sort of hook for AOLserver which disables those parts of Tcllib.)

If the last item above is too problematic, that is probably best solved either by adding additional support to AOLserver, or by tweaking the official version of Tcllib - not by forking the Tcllib code. As far as the additional AOLserver support, there has been some interesting discussion about exactly that on the AOLserver list recently, e.g., cheap cloning of Tcl interps.