Forum OpenACS Development: xotcl support for oacs

Collapse
14: xotcl support for oacs (response to 1)
Posted by Gustaf Neumann on 08/03/05 01:53 AM
Malte: There is no specific need so far within OpenACS to use XOTcl
certainly, oacs works fine without xotcl; so all needs for xotcl are by definition soft needs or installation needs. i certainly believe that the oacs community can benefit from an oo language like xotcl, since it (a) can make your code more readable and shorter and (b) can improve the performance in many places significantly. xotcl has various functionalities implemented in C, which are implemented in many places in oacs in tcl. For example, the invocation overhead of an ad_proc can be reduced by a factor of six by replacing an ad_proc by an xotcl method.

Dave: Is XoTcl available for installation from most linux distributions?
xotcl is part of the active state core distribution (which is the most significant tcl distribution), it is part of tcl aqua BI and part of the Apple developer tools for Mac OS X tiger.

Dave: I just would hesitate to add additional complexity to the OpenACS install.
xotcl is as easy to install as all other c modules for the aol-server. The best thing for a source distribution of open acs would be certainly a single tar file including a version of the aolserver and the set of c modules (including xotcl and libthread) and a toplevel configure-file, where one can do a single (configure; make; make install) cycle.

Nima: All you need are the xotcl tgz and the tcl thread extension..
yes and no. the thead library is used currently only for the request monitor and throttle packages, which is the most probably the best monitor for oacs around (it does not use ns_server and therefore it does not crash under high load). but strictly speaking, xotcl does not need the tcl thread extension.

For real work, you will like some more support: the xotcl objects, classes and methods should show up in the api-browser, etc.; most probably you will like to have the following things:

Both patch files do not harm when xotcl is not installed. The README file for the installation is here http://media.wu-wien.ac.at/download/README.xotcl-oacs

Dave: Also there is a HUGE body of existing code that does not require XoTcl and it seems to be working reasonably well :) I think just taking the ideas of encapsulation and well defined procedures that do what you expect from object oriented programming would go a long way
OACS is implemented already in various places in some latent OO style, which is implemented by hand, not always consistently. Doing this with some programming language support can certainly help. from some postings in the forums i get the impression that there is a certain oo-phobia, maybe from the days of the split btwn. ACS and OpenACS. doing the right level of encalsulation between object and the database is under performance considerations not an easy task, doing it in the oacs-style seems a good compromise. therefore i am not suggesting any radical changes in the oacs architecture. xotcl can help to realize the current architecture in a better and faster way.

Certainly, we can load xotcl fine into oacs, as we did it since four years. For other installations, the use of our xotcl modules is more hassle; many e.g. dotlrn admins are not the best system guys and are somewhat reluctant to go to the installation guides sketched above. Easing these steps would make it easier for us to share code. For the performance changes, certainly the core functionality used all over the place benefits most. It is not so easy to provide a module, that achives this.

Over the last days, i have implemented some improvements for the calendar package (based on the code in dotlrn 2.1.3b) in xotcl. One can now dowload one or many calendars in the ical format (e.g. to mozilla calendar or iCal on Mac OS X), or upload ical calendars to openacs, or share calendars via webdav (mozilla calendar/sunbird/XUL-files for Firefox or Thunderbird only). It works up to some architetural limits quite well. I am not completely through with it, but i can package it quite soon...

Should we maintain two versions of calendar, one with ical based on xotcl, the other one without xotcl? this does not sound very reasonable. xotcl is an ordinary tcl extension. packaging it with openacs is as complicated as nscache or nssha1 or whatever. If it is installed together with the other c-components, it is the least hassle.

Collapse
16: Re: xotcl support for oacs (response to 14)
Posted by Andrew Piskorski on 08/03/05 09:05 AM
Heck, even if there was no other reason for doing so at all, OpenACS should be made to integrate easily with XOTcl out-of-the-box just to encourage further contributions from Gustaf to OpenACS. :)