Forum OpenACS Improvement Proposals (TIPs): TIP #87 (Approved): provide support for xotcl in oacs

The purpose of this tip is to make it more convenient to write and use
xotcl code in oacs.

Reasoning: xotcl is an accepted oo extension of tcl (part of active
state core, tcl-aqua, xdev of mac os x tiger). xotcl is one of the
fastest and most flexible oo extensions of tcl, it is thread save and
proven to work reliably with the aolserver 3 and 4 since years (e.g.:
learn@wu, Zoran's company uses it in their archiware products). xotcl
can help to improve the speed of oacs (by providing functionality
implemented in C, which is used in many places in oacs in tcl) and to
improve the flexibility and readability of the code. xotcl can be
used conservatively to implement the already present object
orientation of oacs in an improved fashion (see
xotcl is TEA compatible an can therefore be installed in the classical tcl
style on practically all common platforms (Active State tests its
releases on windows, intel linux, hpux, solaris, aix, mac os x).

Providing xotcl support means to
- include xotcl c-source like the other c-based modules
(nssha1, etc) in the main distribution; a top level
(configure; make; make install) would be great
- accept the two patches mentioned in
to the oacs core
- include the xotcl-core package in oacs

If this TIP is approved it will make xotcl a required part of an oacs
installation and make it easy for package or core authors to provide
code in xotcl or to use components implemented in xotcl (look e.g. at
the mentioned RDF thread).

As a non-OCT member I would like to strongly endorse this TIP.

Assuming it doesn't impinge on current development styles, making xotcl available can only help and attract developers (which everyone wants).

I personally would prefer to be able to use objects in OpenACS coding and would spend more time on OpenACS (as opposed to Perl and Ruby OO coding) if xotcl was part of the OpenACS core.

Another benefit of adopting xotcl is to pre-empt multiple (different) OO styles being used by OpenACS developers (like [incr TCL] for example).

I would be willing to invest time in any implementation required or regression testing.

I approve under the condition that a documentation for xotcl installation becomes part of our standard installation documents. Furthermore help must be provided for the installer champions that provide packages e.g. for Debian in installing xotcl.

Our installation is already considerably complex, we should strive to not complicate matters further.

Posted by Jade Rubick on
I approve.
Posted by Dave Bauer on
Definitly we need to make sure the install is smooth.

Also I think we would need documentation on how to write OpenACS code with XoTcl and possibly a guide on porting existing code, although that seems like a huge job and I would not necessarily encourge chaning existing code just to chnage it to using XoTcl.

I think documentation would be great and some concepts when to use objects and when standard tcl works better.
I approve.
The OCT reviewed this proposal and agreed that it should go into HEAD for inclusion in the next branch and release, presumably 5.3. It's not clear from the original post who is proposing to do the work; we assume Gustaf will take the initiative, with assistance as needed, especially for documentation.
Great. i will check-in xotcl-core into HEAD. Ideally,
we should not let somebody install the package via apm,
when xotcl binary is not installed; however,
once the xotcl binary is required this no problem.

It seems, that the
requirements for binaries are only checked in:
is this correct?
i will also check in the two patches from

regarding documentation:
installation docs: is it sufficient to more-or-less
transfer the instructions from the README file above to
of the HEAD revision and commit? who produces the html-files?

user documentation:
where should this go? development tutorial? development
reference? What about the following content:
- tutorial: pointing to
- functionality in xotcl-core:
* documentation of the xotcl-specifics for the
api-browser (ad_insproc, ad_proc, and ad_doc)
* using non-positional arguments
* sample using xotcl objects instead of name-spaces
(the simple note example)
* pointing to class descriptions of the api-browser
where appropriate.
Is more needed? other suggestions?

i'll be on vacation from Sat until 14 days later, most
probably without internet access. So most of this will
happen after that.