Forum OpenACS Development: What's on the critical path?

Posted by Don Baccus on
OK, so Dan's got the acs-kernel datamodel ported over (though we'll be wanting some overloaded calls to some of the create-this-and-that routines to simplify porting - hard to tell which to provide until we dive in, though!) I've got the beast auto-configuring based on your database du jour, Oracle or Postgres (easily extensible to others, of course).

So why can't we have this sucker up entirely by midnight? Well, there are a few things standing in our way...

First - I'm leaving for a quick vacation tomorrow afternoon, and will return on next Tuesday afternoon. I won't have net access while I'm gone, but I will have fun (guess which is more important?) I'll get back to those who are interesting in helping with porting, documentation, etc tomorrow before I leave so everyone will know who has offered to help thus far.

Progress will continue in my absence, however. For instance, the folks at Civilution are going to be taking a hard look at current released, beta, and alpha aD packages to try to get a handle on what really works and what really doesn't (you guys might want to play with the new Ybos jukebox, too). I think this will help us pick which modules to port first, and which modules to start discussions on regarding improvements (the content management system, for instance, needs UI improvements and I think all are aware that the sysadmin UI does as well).

There are three near-term critical path items I can identify, which I hope can converge nicely in parallel to some degree:

  • Query Dispatcher

    The auto-configurating bootstrap installer (phew!) dies quickly on a call to an Oracle package (if you're doing this under PG). Rather than kludge our way around this we need a prototype-quality version of the query processor.

    Ben owns this and Ben has been working on it.

  • ArsDigita Package Manager (APM)

    acs-kernel is hardwired into the boot process, but other core packages are driven by the package manager (as they should be). The package manager needs to let the user configure packages to support various RDBMS engines, or needs to figure it out from the locations that datamodels occupy (probably both, i.e. the second as a default overridable by the package creator).

    After that's set up, loading package datamodels for a particular RDBMS engine will be done just as is done now for the hard-wired acs-kernel package. The difference is that the APM will figure things out from XML while acs-kernel is, as I mentioned above, rather hard-wired.

    Also queries need to be "PG-ized" and split out using the query dispatcher before the APM can do its job. This doesn't look like a very big problem, though.

    I own the APM changes as the necessary changes are an extension of what I've done to implement auto-configuration thus far. I'll work on this while I'm on vacation, it will be fun.

  • Core data models

    When the above two tasks are done we'll be able to load data models for workflow, the content repository, etc in an auto-configurable manner.

    However, none will exist for Postgres.

    We could use some help here, probably from one or two folks other than Dan, Ben or me (Roberto's interested in helping ASAP I know). There just isn't enough work to spread around widely for these pieces...

    We'll try to figure out who owns what here soon - if y'all figure it out while I'm incommunicado I'd be thrilled.

In addition, over the next week or two it would be fantastic if we could figure out who will be working on porting which non-core modules. We've had one person (at least) offer to help on documentation and a couple to help with Oracle as well as PG testing, so I'm hoping we can also start revamping documentation as we move along, keeping it reasonably up to date, in particular installation docs.

I'd hope that none of us are too proud to work on docs and testing, but the bitter reality is that we're all doing this in our spare time, and we do have (and will pick up more) volunteers to help with these tasks who also don't feel like they're up to speed on helping directly with the port.

Documentation is as important as the code, and we've all dealt with poorly-tested aD code in the past so I'm sure we all know just how important testing is. Those who don't have the time or skills to dive in and help port but are willing to help with docs and testing shouldn't worry about respect - you'll get it, in spades. We'll make you blush with embarrassment.

That's it 'til tomorrow...

Posted by Jon Griffin on


I think the CMS will be the killer app for OpenACS. That said, as it exists now it is almost unusable by a programmer and good luck with end users (I have tried).

I really think that a straight port of ACS Classic may be the wrong thing to do. For one, I hope that i18n support is built-in and not an afterthought.

Here is a list of some other things I think should be looked at:

  • Templates - fairly complete but still a burden. This may be alleviated if a page builder or something similar gets written.
  • Email for login - I know that I am not the only one who has had requests for not using email as a means of identifying a member. In fact most sites I surveyed don't require email and instead use a handle or username. This is fixable in Classic but a major pain if you want to upgrade. It is actually more legacy cruff leftover from long ago
  • Hardcoded values - My personal pet peeve is seeing reference data or lookups that have hardcoded (either by pl/sql or tcl) values. It is lazy programming at its worst. I can't think of many cases (booleans, y/n, etc, and even y/n could turn to maybe!) where a simple table lookup wouldn't be infinitly more flexible.
Posted by Jon Griffin on
Some more "stuff":

As I attempt to use CMS more, I really think it would be better to redesign the whole thing and do it right. It is not sub-site aware which is a major problem.

Also, we should make sure that all the bugs reported in SDM on should be fixed. There are many with patches already submitted but never applied.

Posted by Don Baccus on
CMS isn't subsite-aware?

Oh migosh, I haven't played with the integrated version, just the
older standalone version, and assumed that this would've been part of

We probably need a side discussion on CMS in general, since it is near
the top or at the top of nearly everyone's priority list.

Posted by Jon Griffin on


I could be wrong, but just mounting it up in a different location didn't work. You still only have one instance.

I didn't really want to look at the code yet so...

Posted by Tom Mizukami on
What's the plan for an intranet module? Is aD going to release whatever they have worked on for 4.x Tcl intranet?
Posted by Don Baccus on
Adam Farkas was going to look into getting unfinished module code
released so we can consider completing such things ourselves.  I don't
know what the story is on the intranet module at the moment, though.
Posted by Don Baccus on
The list Eric put together shows that there are at least some intranet
pieces available, but I have no idea how complete they are ...
Posted by Adam Farkas on
Don -- what code are you after? Eric's bits-and-pieces of e-commerce are already up. I'm looking into the intranet. I'm not sure what state it's in, but IIRC the Tcl version won't be finished, in any case.

I will attempt to liberate code, if I can find it. Thanks.

Posted by Don Baccus on
Since there are some intranet pieces up, the question is whether or
not these are all the existing pieces or not.
Posted by Don Baccus on
Also in the aD ACS Design forum it is pointed out that
version-control4.0d is needed by filemanager4.0a but isn't available
for download.  It would be nice to get that made available...
12: Intranet (response to 1)
Posted by Erik Rogneby on
I've been in contact with a very friendly Mike Bryzek and he will be posting some info about the state of the intranet pretty soon.
Posted by Don Baccus on
That's great news.  Also I see that a development version of the version control stuff is indeed available in the repository, so either the post on the aD bboard was incorrect or someone read it and stuffed  it into acs-repository.
Posted by Jon Griffin on


I like the templates (mostly) and would like to have all the functionality working. Mainly date_widgets don't work correctly, and wizards and some other widgets don't work. Also, the optional flag needs it opposite, (i.e. if there is no optional flag it is mandatory)

I also would like to modify the form handler (if it is even possible) to get rid of all the hard coded html and make it easier for a designer to use. Preferably by allowing EVERY page on the site to be edited from the browser.

Most designers don't want to learn to ssh into a box and fool around trying to find where in the tree the page is. This got much worse in 4.x because of the request processor. Now people have to understand file hierarchies, directory layouts, modules and etc. to modify a page, and many things like errors still have hardcoded html in the various parts. This makes it difficult to apply skins or even change parts for sub-sites.

Posted by Don Baccus on
A couple of folks have expressed interest in templates, it should be one of the first things taken on.

I think you're right about the other issues, too.  Certainly designers  don't want to deal with logging into Linux, etc.  We'll just port straight-up first, because templates are necessary for almost everything within the system.

We need to get the SDM set up so we can start tracking feature requests.  Talking about features here is fine but a pointer in the SDM attached to the specific module will help ensure ideas don't get lost.  Coupled with Roberto's maintenance of a TODO list we should be in pretty good shape for now at least.

Posted by Roberto Mello on
Feature requests are in the SDM already, we just need to create appropriate modules in the openacs-4 project. Then I'd suggest Jon to post this (and other suggestions) up there.

As for the TODO list, I'll hack something together today and post a link for review. I'll try to make it an add-on to the SDM so we can be consistent.

Posted by Don Baccus on
Have you looked into using the existing todo module, which is already integrated to some degree with the SDM?  Someone else mentioned the possibility of using this tool...
18: Templates (response to 1)
Posted by Kapil Thangavelu on
templating should def. be on the critical path considering that
their used by every application package in the acs4. i've skimmed
through the code and it looks as though it should be a near drop in
for functionality. the db dependencies seem to be nonexistent except
for api calls to the db.

i'd like to clean up some of the redundancy between the templating
system and the db_api. there are still some artifacts in the
templating system reflecting its design to be a standalone system.

keven scaldeferi put up a nice overview of the request processor and
templating in a wimpy point presentation. the last page goes through
the workings of the templating machinery although it leaves out the
compilation to a proc (which can be inferred from the code::

Posted by Don Baccus on
Well ... it looks like you've looked more closely at templates than I have, and most likely anyone else - do you want to take it on?

I just need to integrate Ben's preliminary query processor with my minor APM changes to handle multi-db aware modules and we'll be ready to start rolling.  Dan's got the content repository ported, at least far enough to have checked in files (not sure how much testing etc has been done).

I kind of hate to jump the gun like this on other folks but you're right, templating need to be done right off the bat.

Yes, the db_api redundancy needs to be stripped out and the quicker the better.  If we wait it will likely continue to linger in the code base.

Posted by Ken Kennedy on
If todo is indeed (even partially) integrated with SDM, then let's
definitely use it! Ah! Found SDM in my install...excellent!! (If it's
not in the doc subdir, I probably don't see it...*grin*). How soon
'til we can create modules in SDM?
Posted by Michael Bryzek on
I apologize for the delay in posting a reply about what's going on with the intranet module at ArsDigita.

If you're subscribed to this thread (, you've already read seen this. Otherwise, I hope it's helpful. Thanks again for all your patience regarding the intranet package.

We were trying to figure out what the best path would be for the intranet here at ArsDigita. We decided to abort further development on the Intranet package for ACS 4 TCL in favor of speeding up the development time to release core support for Intranet functionality in
ACS Java 4. The overall idea is to port the ACS Core enhancements made in ACS 4 TCL to ACS 4 Java and to complete the ACS Core work that will make it easy to develop an Intranet that is customized to the particular site needs.

Note that almost all the work done on the intranet through early march is available in ACS 4.2 TCL.

More details will follow, but as of now, there will be no release of an Intranet package for ACS 4, TCL or Java. Instead, ACS 4 Java will be enhanced to make it easier to develop an intranet package should somebody be interested in doing so.

In the meantime, we've made available a pre-alpha version of an offices package that demonstrates how the pieces fit together - from using the groups system to model offices to using portals to display information about the offices. This package is very rough and has known bugs, but we hope it will be of use in terms of seeing what type of intranet functionality is provided inside ACS 4.2 TCL. More information on the offices application and how to install it can be found at:

Posted by Kapil Thangavelu on

i'll work on the templating.