Forum OpenACS Development: Re: OACS 6 and beyond

Collapse
61: Re: OACS 6 and beyond (response to 1)
Posted by Gustaf Neumann on
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.

Collapse
Posted by Rocael Hernández Rizzardini on
Gustaf, moving oacs to oo might be the next path, specially to grow and distinguish, maybe you can set a wiki to put together your ideas, and the interested parties can comment on that.

Besides technology, making easy for new commers will be important factor if we are going to put an effort, this means easy ways to learn and be productive.

Collapse
Posted by Jun Yamog on
Moving to OO doesn't mean its going to be easier and productive. It may do it considering starting from 4.x the db schema is not traditional and OO-like but its not guranteed.

I was chatting with an ex-aD developer regarding this thread. Contemplating on history, it MAYBE all the power and complexity of ACS 4.x that scared new comers. That wasn't much an issue during the 3.x days, in fact its just like doing PHP only much more sane and easier. The 3.x codebase was easy to pickup and the output cycle was shorter (near instant gratification to a developer).

Anyway I don't want to muddle the thread any further since the decision to make ACS OO and make it powerful yet complex was decided years ago by aD.

Collapse
Posted by Rocael Hernández Rizzardini on
Easy to learn sometimes is just at least: good tutorials & wikis, and ways to keep them up-to-date (probably making them part of the process for new pieces of code that goes into the core), these is something that we don't have even with the actual openacs.

Probably the target audience is not newbie programmers such as PHP seems to have. We might like to target professional - competent programmers that OO, DB and webservers is not something new, probably already mastered, those that care about programming, then those ones can try, realize and see the power of openacs as a web framework.

Collapse
Posted by Malte Sussdorff on
I just had a discussion with an experienced PHP developer that I converted to OpenACS. He mentioned what is irritating is the fact that you have to deal with three files for one page and that variables are automatically set in each of them, without an explanation.

Example:

- If you call db_* you do not know which variables are returned in the tcl statement. So if you are searching for the variable you have not much of a clue, unless you look into the .xql file(s). So extending db_* calls with a documentation part that allows us to write which variables are expected to be returned could help

- This is especially true if you enter the variable in the .adp file without even calling it in .tcl.

But I agree with Rocael's assessment, we should not try to target the same group of people that PHP is targeting, for this OpenACS is just too complex as a framework.

One note though on XoTCL. Before we move forward in this direction, we definitely need training materials which describe common tasks as done before and how they are done afterwards, so we do not loose the experienced developers that OpenACS has at the moment. And obviously we should stay backwards compatible, so the old style of development still works.