I do fully agree with Don, that no one should hold the breath until
we are able to provide a fully functioning higher level api to handle
all the stuff that current acs-core + dozens of packages require.
That's a task for 6.0, and not 5.3.
In the past, i have implemented various active record implementations
in xotcl (see
e.g. https://openacs.org/forums/message-view?message_id=185330), which
is highly flexible but has the problem of accessing the database
mostly by one tuple at a time, leading to bad scalability for some
tasks. The approach used by the for the oo-layer for the content
repository in xotcl-core is much better in this respect, but not a
full-blown generalization. i have seen and discussed the database
abstraction layer and persistence layer from Neophytos, which is in
many respects much more radical, but a very promising approach. But it
needs time. We have hired Neophytos for our EU-funded iCamp project,
so Neophytos will be able to spend some resources for completing and
polishing it.
The big question for me is how radical changes to OpenACS should/could
be in future versions. We have one of the largest installations of
dotlrn and have therefore as well interest in a stable core and dotlrn
packages, but at the same time i have often desires to change
fundamental pieces of OpenACS. We are in competition with other
environments catching up. To keep the lead, we must be able to make
significant changes. Just to use xotcl and keeping things as they are
does not help much in this respect. For example, as discussed earlier in
the forums, i have re-implemented ad_conn in xotcl, which is faster by
a factor of 10 compared to the current implementation. However, this
plug-compatible implementation tries to deal with the idiosyncrasies
existing in ad_conn. This is by no means a nice and well-designed
piece of oo software. I have no big interest of giving the software
out of my hands since i am rather afraid that someone would see the
code and ask me what strange kind of software i am writing. Why?
ad_conn is for example "always around" as a command, has its own logic
of being configured and initialized etc. Conceptually ns_conn and
ad_conn are objects keeping connection specific information. These
objects should be created when a connection thread becomes active and they
should be deleted when the connection thread has finished processing
an http query. There should be a connection class with the ability to subclass it. In
trying to be 100% compatible with the old version, it uses the strange
ways of being configured which are not needed in an oo language. I
made very similar experiences with templating. Although OpenACS is
object based in many respects, turning it into an true oo architecture
based e.g. on xotcl will change many things. If one would try to do
such a transformation piecewise on the existing acs-core, this would
require many TIPs, some of these would be rejected by developers with
many customers running legacy code.
From my point of view, the only approach for substantial redesign
within OpenACS is sideways development. The new code must be able to
co-exist with existing code, which is certainly possible with the
AOLserver. Another approach would be to start all over with a new
project - but this will take even longer until it will be ready for
primetime.
My goals are not to improve the speed of certain functions by an order
of magnitude, but to create the best and most cool web framework to
attract people joining our forces. To achieve this we must be more
attractive and better than RoR (which is not so hard). XOTcl is so
much more flexible than Ruby, so we have our chances. If we don't
succeed to create a vision, the fancy past of Alex and co will fade
over time.
In some respects, xotcl-core and xowiki is for me a project to test
our some oo ideas within OpenACS. Although i am not a friend of
announcements about things to be available in the future, i have to
say that we are pretty far with xosoap and xorb, which is a client and
server web-service environment for openacs based on xotcl. It will be
released in the not-to distant future. Neophytos uses my COMET
streaming technology (part of xowiki chat, see
https://openacs.org/xowiki/pages/en/chat) on phigita.net and he seems
very happy with it. We did already some work on templating, and with
Neophytos database and persistent layer, we are on a good track.
Concerning the Oracle thread: The main issue is maintenance. In the
best of all possible worlds, we are able to generate in the future
most of the application packages code. If the generated code has
interfaces for handcrafting, and is able to co-exist with a small
fraction of manually maintained code, maintenance should go
significantly down.
