Forum OpenACS Q&A: ETB .. Entry-level Tcl Beans ;-)
working on an extension to Tcl that will work within the AOLserver 3.x
providing an object oriented api that hides the persistence layer.
The api is called RCO and is designed to be compatible with all
versions of Tcl based ACS. Currently it has been successfully
installed on ACS 3.2, ACS 3.4 and OpenACS 3.2.5. There are only a few
low level changes that would need to be made to make it also run on
ACS 4.x distributions. The main connection between RCO and ACS is the
use of the ACS user management systems. In this way RCO can be seen as
an ACS module that can be used along side all other modules. In
particular I have written a CMS application on top of RCO that is
therefore immediately available as a module for all ACS 3.x
distributions.
I am posting this here because I have just put together the first
distribution of RCO that has been successfully installed on an OpenACS
server (previously I have always been using it with Oracle backed ACS
3.x servers), and so I am curious to see if RCO is at all interesting
to people in the OpenACS community. Here I will just explain a little
more about RCO and then give a link to the distribution download.
As well as providing an OO extension to Tcl, RCO expresses a
development philosophy that encourages the use of an explicit
application layer separated from the persistence layer. RCO currently
has two persistence devices implemented - an SQL storage device and a
filesystem XML storage device. The idea is that code written above the
RCO api need not know which of these storage devices are being used on
the given installation. The SQL storage device has been successfully
used with both Oracle and Postgres. It is therefore possible to use
RCO to set up a User object that interacts with the ACS users table.
Other storage devices could be developed (such as remote storage via
SOAP) and each class can define which storage device it uses for which
data it holds.
RCO also encourages an event driven style of web programming. All HTML
design templates are objects, and all web pages are created by viewing
a data object `through' a template object. All web forms are created
by templating characteristics of the data object being viewed,
including the submit buttons which are seen as possible `events' or
actions that a user can perform on the data object. In this way there
is rarely the need to think about CGI parameters as a programmer
within the RCO environment. You simply have to define which actions
people can perform on each class of objects, and then template the
display page. RCO also has a web based development environment that
allows people with the correct ACS permissions to create new classes
and debug existing classes whilst the server is running.
On top of RCO I have written a set of objects that together form an
Object Management System (OMS). The OMS provides a web based interface
for managing personal and group folders of objects. For example, you
can create new objects, edit them and move them around from folder to
folder. The basic objects provided by the OMS include workspaces,
folders and HTML template objects. All OMS objects inherit from the
OMS_Basic class which gives them the properties necessary to be
managed.
On top of the OMS I have written the basics of a content management
system (CMS), all of which is written as objects that inherit from
OMS_Basic. This CMS system includes objects that let you build up a
web site and manage the content of the web site along with the
templates for the web site using the OMS interface. Permissions are
handled by the ACS users and user groups permissions system.
The web site later.runtime-collective.org is currently running on
this CMS and it is possible to download a distribution of RCO for
OpenACS from this web site at:
http://later.runtime-collective.org/oms-site/later/home/rco-doc/instal
l
I am slowly developing some on-line documentation for RCO which is
available at:
http://later.runtime-collective.org/oms-site/later/home/rco-doc
As I've said, I am very curious to have any feedback from the OpenACS
community to know if RCO could be at all useful to OpenACS.
PS I wish it was in Cambridge UK that you were having your social
tomorrow as then I would definitely come along 😟
http://later.runtime-collective.org/oms-site/later/home/rco-doc/install
RCO requires nsd8x, aolserver clock function in particular cd /home/aol31/bin rm nsd ln -s ./nsd8x ./nsd
This RCO system looks really interesting. Would you give us more information like the status of the system?
However, I will just mention that it is NOT yet in production status. I am using it as the CMS to run a web site (later.runtime-collective.org), and so far it has proven effective to use and fairly stable behind the scenes. However, there are features missing from each layer that I think need to be added before it's ready to be a version 1.0 release.
My posting here is as much about seeing whether there are people who may be interested in using RCO as an OpenACS module.
Once the status report document is finished I will post a link here.
In principle, this looks interesting. In practice, it will look a lot more interesting after OpenACS 4.x is released.
Since you're not at the production stage yet, and since we've not released OpenACS 4.x yet, a timely convergence of folks' having more time to poke around and explore your stuff and you're being satisfied with its status as production work seems possible.
We've already rewritten the OpenACS 4.x content repository to provide both in-RDBMS and in-filesystem storage, with a common API, so at this basic nuts-and-bolts level we're thinking somewhat in common. The 4.x content repository also provides some of the object management you mention - folders, etc - and our goal is to move all content into this framework. In particular this will simplify site wide searching, which should only have to search in one place, i.e. the content repository.
It should flatten the learning curve a bit, too - right now you need to learn how bboard uses its own custom repository, how certain other packages store content "by hand", and how "proper" packages use the content repository. Much of this is grotty and ad-hoc at the moment.
Despite this similarity of thinking, the approach taken by 4.x is totally different. The object model lives in the RDBMS, rather than in the Tcl layer. Your approach appears to be much closer to what aD is doing with their Java re-implementation. There's a lot that can be said about trying to pound the object model peg into the relational model hole, mostly negative things, so I'm not going to claim that the approach taken in 4.x is superior.
However, it's there and in the near-term, at least, we're stuck with it. So I have questions as to how well your work would meld with the current OpenACS 4.x object model. Have you looked into this at all?
http://later.runtime-collective.org/oms-site/later/home/rco-doc/future
As regards ACS 4.x I think there is a good possibility for some very effective synergy between RCO and the ACS 4.x object model. I have not had any real exposure to using ACS 4.x, but I have read a fair amount of the available documentation. It has led me to believe that there could be a very complimentary match between the 4.x object model in the RDBMS and the RCO objects in memory.
In particular it may be possible to use RCO as a `memory resident cache' of 4.x objects. RCO could be used to manage persistent sessions for users who are, say, performing a lot of editing of content. During the session RCO would manage in memory a copy of the various objects being used in the editing process. This would reduce the number of database interactions to one initial set of selects followed by a few updates when content is saved. Indeed this may even let one database server effectively service a farm of web servers. Once the session is over, the objects are de-activated and the memory recycled.
To achieve this an RCO class called ACS_Objects could be set up as the RCO mirror of the acs_objects table. All application specific objects would then inherit from the ACS_Objects class. Various useful methods would be defined for the ACS_Objects class and thereby be available for use with all ACS objects. Application specific objects would extend the basic class with extra data elements and methods.
RCO is already set up so that the different data elements within one class can be mapped onto columns within different tables in the RDBMS. This way an RCO class can behave like a view on the database .. but a view that you can write to as well as read. So, an ACS_Notes application class, that inherits from ACS_Objects, could map data elements onto both the acs_objects table and onto the notes table.
Another area where the RCO code base could be interesting to ACS 4.x is in the development of new objects. RCO already has a web based development environment where new classes can be defined along with methods associated with the class. In the RCO environment these class definitions are then translated into a Tcl file of RCO procedures (a bit like proc_doc calls) that actually create the class. The Tcl file is created, saved and re-loaded (using the ACS 3.4 `watch' code) so that the new class is instantly available for use. It shouldn't be too hard to extend this functionality to be able to spit out the necessary code for creating an ACS 4.x object as well (such as the PL/SQL procedures ..etc). However, I have no experience of writing these object definitions by hand, so I don't know how easy this would really be and whether or not these object models can be re-loaded.
So, although I don't know the details of ACS 4.x I am very excited about the possibilities when RCO is made compatible. Realistically it wont happen for at least a couple of months. As you mentioned, Don, hopefully the first OpenACS 4.x will have been released by then and so I can use it as the basis for making RCO compatible.
