Forum OpenACS Q&A: Top Ten Priorities for OpenACS ... what are yours?

Here's my own personal list of things I want the OpenACS community to do, based on problems and obstacles I encounter every day. In no particular order:
  • Release 5.0
  • Test 5.0
  • Produce and maintain automatic, packaged install including prerequisites (rpm, .deb)
  • Produce and maintain automated testing suites for all core packages
  • UI improvements to bug tracker
  • More OpenACS bundles, including generic usable bundle (ie, usable "out-of-the-box" OpenACS site with most popular applications
  • UI improvements to group/user management
  • New UI for content management
  • TIP package to automate TIP process
  • Upgrade to OpenACS 5.0
Welcome, new OCT members!
Posted by Dave Bauer on

Produce and maintain automated testing suites for all core packages. I have been using the automated testing package in developing WebDAV support and it is greatly helpful.

Tcl API for the content repository. A complete Tcl API, to reduce or eliminate the need to have pl/sql to access the CR in an application package, will facilitate building better user interfaces for Content Management.

Before we upgrade to 5.0 we need to upgrade to 4.6.3! Hopefully done before the 5.0 release.

Posted by Alfred Werner on
Upgrade to AOLserver 4.0+

Integrate better with 3rd party (non-aolserver/oacs) TCL packages - e.g. evaluate TCL core, tcllib, cURL, etc. If we don't like those packages, contribute back to the TCL team.

Code-generation from a XML or other formatted spec/template/langauge for rapid dev and more consistency in DML,forms,permissions, etc

Central APM repository that an installed site's admin can query against/upgrade from with support in the /admin hierarchy to do this.

A good webmail package.

Ability to use the system to spam arbitrary members (like in the 3.x systems) from the admin screen.

Ability to add 'prospects' to the system, without giving them specific membership in the system. In other words, when they go to sign up, the system doesn't say "sorry, you're already in here - want us to email your password?" And then the ability to spam these people, as mentioned above :)

Posted by Dave Bauer on
Alfred, thanks I forgot about using standard tcl packages. That is a great idea.
Posted by Mark Aufflick on
ditto to the following:

* 5.0
* OpenACS-in-a-box
* CR + CMS
* AOLServer 4.0
* WebDAV
* tcl library friendliness

plus the following:

* some clients to use it with ;)

Posted by Malte Sussdorff on
Random thoughts, no order, trying not to repeat things already said:
  • Small perl/bash script, that will upload a patch to openacs like this "upload-openacs-patch #bugnumber #filename(s)". In other words, make it as easy as possible to provide patches to OpenACS
  • Knoppix CD with OpenACS out of the box.
  • Structured approach on OpenACS marketing.
    • Creation of OpenACS marketing material
    • emails
    • signup OpenACS to conferences (and try to get reductions).
    • Coordinate press releases about OpenACS. Installation of a press module for monitoring all published information about OpenACS on
  • Expand the user base.
  • Talk about work that is beeing done, try to avoid double developement.
  • Single signon gateway which would allow us to easily use e.g. squirrelmail as a webmail system or integrate other systems.
  • Install Jabber functionality in
  • Sort out and resolve the CR discussions
  • OpenACS social beginning of next year in Germany
Posted by Alfred Werner on
Oh yea - one more thing :)

Smarter logging. What I'd like to see is:
each and every package has a loglevel and a show-boot-messages parameter. Boot messages are either shown or not, log messages are filtered based on the level set for the package. The current system spits out so much information that I rarely bother to look at it. When I do suspect a problem, I contrive a test scenario, flush the log, and restart anyway - mainly because there's too much in the logs to figure out what's wrong.

The logger system would have to know that it was finished booting.

Having done that, run through the packages and stratify based on actual severity - Notice/Warning/Error.

I'd like to keep it set to a Warn/Error level when things are going OK and crank it up when there's a problem.

A system setting (acs-kernel?) can override the above for the entire system.

Is it possible to convert (or hack aolserver) to write log files in XML format, then pass this through a streaming parser
to dynamically generate meaningfull log reports based on some user specific parameters?

Posted by Peter Marklund on
I like the logging proposal, it reminds me of Log4J ( which I have found to be excellent to work with. Maybe you should write a TIP for this?
Posted by Alfred Werner on

I read the paper (quickly) and here are my thoughts:

1. I was referring to the "error" logs, rather than the access logs.
2. Most sites don't bother with realtime reporting on access logs, rather, they roll them daily and run report software against them (largely due to size). While this would allow a means of providing realtime logs, the bloated size of already overlarge log files would be too much. I'd rather see them go the other way - normalize the acccess data.
3. If we converted the access logs to XML then only one piece of software could read them. Currently there are at least dozens of good packages out there to do whatever reporting people want.
4. I can code XML but not XSLT.
5. I don't have a personal need / desire to see it happen.

Posted by Alfred Werner on
I'll write it up. The one thing I want to think through first is interaction with syslog, which currently doesn't happen. I have a pretty clear idea of how I'd like this to work.

I think we'll need to add a facility, which ns_log doesn't require, because I can't think of any way for the new log function to tell what package it's running in. Also, it would probably make sense if a package is mounted multiple times, to tell which instance is having the problem. Again, I'm not sure how to tell that at runtime, but I'll experiment.

Once I have a clear, specific proposal (i.e. working code) I'll TIP it :)

As an aside, on the logging front, I also opened bug to get the cookie/user_id code installed by default in the config.tcl. Also noticed another bug report requesting logroll be turned on by default for error.log - nice to see the sysadmins are getting taken care of!

Posted by Lars Pind on
I'm not sure if Joel intended for this to turn into a general wish-list thread. We have plenty of those already.

I'd really like to hear what people really, seriously think are top priorities, the most urgent ones. The things that would help the software mature and the community grow.

My personal list is very similar to Joels, but I've added some reasonings:

1) Release 5.0 (software only matters when you ship it)

2) Test 5.0 (we've found too many trivial bugs lately)

3) "One-click" install (people need an easy path to test the software

4) Automated testing  (improves quality)

5) Documentation improvements (distribute best-practices, improve quality, get more people contributing)

6) UI standards and improvements for applications (makes our software more usable and useful)

7) CMS UI (most sites start with CMS, and we're so close but no cigar)

8) Upgrade to 5.0 (many important new things, it's important that we get back to the trunk)

9) Fixed 3-month relase cycles (gets us in the habit of shipping, lets our users know what to expect, helps users not fork from releases)

10) Solving the metadata riddle (we have so many half-complete data dictionary/metadata-style things, we need to get one and get it working)


Posted by Tilmann Singer on
I agree with Joel and Lars and would only like to add one point that appears crucial to me for better involving newcomers and deal with contributions more openly and quickly:

*) Package maintainers

At least every package which is in the main distribution should have one person prominently listed as responsible for it, who should act as a central coordination place for development on that package.

Posted by Don Baccus on
Well, there's nothing above that I can disagree with.  That's a good list up there, lots of crucial things.

Offhand, the only addition that quickly comes to mind is to continue our efforts to migrate more API stuff to Tcl to support rapid development.  In the past few months we've implemented high-level, declarative approaches to ease the defining of service contracts, portlets and applets and there's a lot that could be done with the content repository that would make the writing of content packages much, much simpler than it is today.

I would like to see us define coding standards and to move existing packages towards using them.  I'd love to see all forms created by the templating package, for instance, preferably using ad_form.  We can do a lot to cut the learning curve that must be mastered before one can be productive using the toolkit.

Posted by Joel Aufrecht on
If you have thoughts on this, even if they are complete duplicates of
other lists, please post.  Newbies especially, please post.  My
purpose is to generate a sense of what people want urgently, and while
if we put it all together we get a wishlist, if we look at the
commonalities we get priorities.

Of course, the next question is how we execute on those priorities.
My sense is that there are two main ways that OpenACS development
occurs: either a paying client needs something incrementally advanced
from what the toolkit does, or one of the core volunteers dedicates a
few days of furious coding to knock off something.  While we can't
really make demands on our volunteer heroes, we can express the things
that we think are most urgent and most helpful.  I also would like to
see the core team identify some more avenues for work to get into the
code base.  One is code patches, which we've heard before haven't
always been picked up frequently enough for contributors to see
positive results.  Another is package maintainers, a process we
haven't managed to get working yet.  If people have suggestions, or
descriptions of what's working on other open-source projects, please

My Top Ten:
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore,
- more usable forum,
- more usable filestore.
Posted by Dave Bauer on

We are in agreement. I think one way to ease development is to remove the requirement to write pl/sql code as much as possible. There are already some ways to do this in the toolkit. Right now acs-service-contract has a Tcl API which is much easier to use than the pl/sql calls previosuly required.

We should continue to build these types of tcl apis for most pl/sql functions. In addition to required less database specific XQL files, it also allows for additional features such as caching to be centralized.

Posted by Jeff Davis on
I think my priorities are:
  • More duplicated functionality. We definitely need forums-lite-new and lite-forums-threaded to complement current packages
  • Longer function names (eg. I find ec_price_price_name_shipping_price_tax_shipping_tax_for_one_item nowhere near descriptive enough).
  • More deprecated procs, although said deprecated procs should be used pervasively in the toolkit.
  • Service contracts are too easy to debug. We need to add at least two more layers of abstraction there for them to be useful.
  • Our markup is too clean. We need more tables, we need much more hardcoded styling and more physical markup. html 2.0 transitional would be a good goal.
Posted by Andrei Popov on
I'll second the last one :)

Besides the obvious (ship/test/upgrade to 5.0) ones, I'd say documentation is *extremly* important.  All the plethora of vaorious how-to's that many people were posting here and there how each particular core module works/can be used/can be abused -- would be great to have it in a single place (a Knowledge Manager?).

Remembering ACS3 days, I'd say that it was a lot easier to jump the wagon back then -- even if things were a lot less elegant.  Now it is quite tough -- and there are no guarantees :)

Posted by Roberto Mello on
I agree wholeheartedly with Don and Joel here.

About package maintainership perhaps what we need is to clearly define how to become a package maintainer, or cease to be one.

In the Debian project this is done through submitting bugs. When a Debian developer plans to package a piece of software s/he submits a bug called an ITP (Intent To Package).

When a developer wants to "orphan" a package s/he maintains that s/he no longer can/wants to maintain, s/he sends a "ITO" (Intent To Orphan) bug. When a developer wants to adopt an orphaned package, a (you guessed it) ITA (Intent To Adopt) bug is sent.

All the other developers see these actions. What we need are clear instructions on an easy-to-access place on how one can go about taking maintainership of a package and what that entails. Perhaps we could borrow some ideas from Debian in this regard.

That should probably go in the page.


Posted by Jade Rubick on
I'd say:

- better documentation
- more tutorials on how to do things and how to get involved
- refinement of ad_form

For the last item, look at my documentation on ad_form:

If I was starting out and I looked at that page, it would scare me off of using ad_form. Maybe we should either be very clear that ad_form is just for simple forms (and then document the underlying form builder code better), or improve ad_form and the form builder to handle these cases better.

It seems to me that ad_form and the underlying form builder has some deficiencies with dates and multiple items. I go through all sorts of contortions to make ad_form work. It shouldn't be that hard.

- an OpenACS wiki to host some of these tutorials. I'll contribute all of my OpenACS content.

1.  A forum especially for beginners. For some people posting to the forums is like a first year student being pushed into graduate Quantum Physics. There are 6000+ members but how many 'regulars'?

2.  A usable CMS UI. Just copy (legally) an already successful one and graft the functionality. Then put it in the 'out-of-box' version of OpenACS (along with some attractive design templates) so that new user can start adding content quickly/effortlessly 2 minutes after restart. Once this is there, they will find uses for the other 'dynamic' applications. The Redhat CMS UI looks good to me. Is it legal to take design cues from it?

Posted by Torben Brosten on
Here's a wish..

to parameterize or somehow externalize all html/css coding and other factors of packages that can (and likely) vary by installation, such as OS, style etc. (Partially ongoing with TIP Nbr.8)


1. Calls to noncore applications, such as ispell could reference a parameter or some kind of package config file with the ispell filepath.

2. Embedded html, css and templates could be referenced via parameters as default values. This way, the defaults can be included in CVS, and changed without negative consequences from varying from the defaults.

Separating site content from OpenACS technology decreases the overhead in keeping a site current (not to mention making it easier  to manage installation variations).

The idea here is to increase the number of CVS development, beta, and release subscribers (and thus their participation in the process). When the number of CVS subscribers increase, the loop between bugs, bug fixes and site updates (as well as external feedback and suggestions) gains momentum. The participating community grows and everyone benefits.

Posted by Rafael Calvo on
It would be nice to have an IDE like Eclipse ( that could generate an openacs package. Any ideaas about how to go about this?

There will be a student in my lab (next year) working on EML (an educational modelling language) probably using ArgoUML. He might be working in getting the UML tool to generate things that could be used by dotLRN & openacs.

Posted by Caroline Meeks on
As you know from my platform article my priorities are in some ways very different.  Its not that I don't share and value the technical priorities, rather that I also want to bring to OCT a focus on increasing the amount adoption, developers and $$ for OpenACS.  This is the underlying fuel that creates our ability to move forward on our technical priorities.  Adoption is also what makes all the work we have done worthwhile.

Similarly I want to increase the amount OpenACS gets back from its adopters, by enabling and encouraging developers and organizations to participate.

Specific things I am working on accomplishing in the next few weeks.

1.    Get the TIP and OCT processes working smoothly, predictably and professionally. I think this will encourage developers and organizations to engage with us. Specifically we need to clean up the TIP backlog and get in the habit of following the procedures as written in a timely manner.

2.    Marketing to Nonprofits. I am working on a presentation for Boston's NTEN conference. I am also starting to collect case studies and putting them at Help would be much appreciated. Davb is working on upgrading to 4.6.3 then we will install photo-ablum to display screen shots.

3.    Talking to people in the community and encouraging them to upload code into contrib and looking for ways to encourage collaboration and involvement.

Posted by Eric Wolfram on
It's interesting to me that the post that started this thread says:

"UI improvements to bug tracker"

It's interesting because that's the reason I looked at the OpenACS site today in the first place. I was thinking about using access atributes in the href for adding new issues -- so you could alt-a to add a new issue or alt-shift-a to pop a new browser and add a new issue.

I wanted those options on the bug page and the bug-add page (so that users could save some keystrokes when they want to add more then one issue that relate to the same thing.)

My team just finished logging and resolving 380 issues in the ACS 3.2.5 ticket tracker, new-ticket. I like how the summary page could be sorted by Ticket type, Ticket assignment, Status, Creation Time, ID v, Project,  Status,  Severity,  Assigned,  Deadline,  Subject, (that little v lets you toggle between assending and decending order.)

The bug tracker in OpenACS 4.0 relates specifically to tracking bugs in software and releasing patches to fix them. I like how 3.2.5 ticket tracker doesn't relate specifically to software "bugs". It tracks "tickets", not "bugs". This gives it better range because, for instance, it can be used to track anything -- like your customer's requests or who your books are loaned too -- without being confusing to the people who use it for that.

So I guess I wish the OpenACS bug tracker had an easy way to change the verbage globally across the application -- instead of bugs an admin could call them "issues" or "tickets" or  or "service requests" or something else.

to stray from the topic a second...

eric -- the 4.6.3 bug tracker lets you choose between a "bug" or "ticket" version when first mounted.  ticket doesn't include the submit patch features.

Posted by Ben Koot on
Hi folks,

1. From a users point of view, ask this same question to first time visitors of, and put this prominently on the homepage. That will give developpers a sense of what John Doe is looking for, without getting distracted by technical challenges.

3. Make available all information about adding design features to the toolkit in a format normal people can understand. Right now I have to dig deep into the forum to find usefull information. Maybe we have some folks that have managed to do what the toolkit was designed for, and concentrated on design, rather than database development. I think you folks could add some very valuable information, that would help administrators and users of the tookit.

PHP nuke comes complete with a few default skins that can be changed by toggling. I can't imagine something like that is not possible with OACS, but, i havn.t got a clue about technology. Anyway, I thik it's a nice fature.

In general I think you are doing a great job, and once you get used to find creative ways to bypass problems, it all works fine. Thanks a lot.


Posted by Caroline Meeks on
Ben writes:
1. From a users point of view, ask this same question to first time visitors of, and put this prominently on the homepage. That will give developpers a sense of what John Doe is looking for, without getting distracted by technical challenges.
I like this idea Ben. I put a survey on my site.

Was this what you had in mind?

We can put one on once its upgraded and we can install survey.

Posted by Ola Hansson on
1. Calls to noncore applications, such as ispell could reference a parameter or some kind of package config file with the ispell filepath.
The path to ispell is detected upon server startup. Isn't this solution preferred to a package parameter in acs-templating (where spell-checking belongs)?

Of course, if both ispell and aspell is installed on your box, aspell will take precedence. So if you'd rather use ispell in that scenario, you may accomplish it by uninstalling aspell from your os and then restarting the server.


Posted by Torben Brosten on
Automatic detection is wonderful. Maybe the autodetected values could set defaults in mainsite parameters, so that if auto-detect fails, values can still be changed (and overriden) conveniently? Maybe this is how its done in 5.0 packages?

The wish is inspired from ecommerce pkg v4.6.1, where ispell is hardcoded at ../packages/ecommerce/www/admin/tools/webspell

Posted by bill kellerman on
first, i wholly support jeff davis.

second, my suggestions deal more with the learning curve of oacs.

- gather the various, scattered openacs documentation and make sure it's all up-to-date.

- present a clearer community view of best-practices, methodologies, suggestions for site planning and development with oacs.  more examples.  encourage users to submit case-studies.  maybe set up a specific "educational" area of for users to share their suggestions and experiences.

- require packages maintainers to document the scope, requirements, and status of their packages.  the community should "certify" packages (ie. a community-recommended package) by reviewing quality, completeness, qa-testing and value.  require package maintainers to document and communicate the status of their packages to the community or risk losing certification.  clearly document packages that are not certified, and what the ramifications are for using them.  encourage users to get their packages certified.

- easier install.  i've installed oacs many times on a few different platforms.  it's slightly tedious with plenty of finger-crossing.

- offer precompiled binaries for different platforms of the different software pieces required for installation

Posted by Joel Aufrecht on
Since we don't really have many active package maintainers at the moment, would it be wishful thinking to ask each person who is making requests of "the package maintainers" to themself commit to maintain a package?  I'll commit to maintain photo-album, if nobody else is doing so.
Posted by Dirk Gomez on
I think we should do that. We need package maintainers to foster and grow the sense of responsibility among OpenACS participants.

Doing it yourself is the safest of way of getting it done :)

first, let me say that i think the oacs community has done a great job so far and is very easy and helpful to work with.  i don't want to give the impression i'm bitching or criticizing and expecting everyone to do my work for me.  i agree -- if someone has the time and inclination to make requests, they should be willing to support making them happen.

it seems that oacs veterans have a big burden when recruiting new contributors in communicating the why's and how's and peculiarities of the system.

my points one and two would go a long way towards handing things over and sharing the load.  people new to the oacs are at a disadvantage by not knowing the backstory (why are there three different versions of ticket tracker?  are we supposed to use the one that doesn't break?  which one does everyone else use?  if i want to develop something with it, which content management system am i supposed to use?  do i use ad_form even though half the code in other packages don't?  why don't they?  just examples...)

point three -- would i volunteer to maintain packages?  you bet.  considering i'm an oacs beginner right now, would that be a good idea?  probably not.  but i can sure offer moral support!... and let you know the point of view of new users.

Posted by Sean Harrison on
I've been reading this thread with great interest, but I'm replying to Joel's query for input from newbies.

I think I qualify in that regard. I have been working with OpenACS for about five months, completely in my spare time. So I'm not yet productive as a developer, but I think I'm far enough along that I can see how things fit together.

As a result, there are three things that would significantly improve the functioning of OpenACS, as I would use it.

#1. Content-based URLs everywhere, based on position in the web hierarchy and the content of the object.

Currently, OpenACS presents many object URLs that include database query syntax involving the system-internal object ID. For instance, bug-tracker, forums, and file-storage all present a URL that includes that syntax.

By contrast, the edit-this-page package presents URLs that are content-oriented, which hide the object ID and the database syntax from the user.

This should be the system default: To hide the object ID, which is not meaningful to the end-user, and to present a permanent URL that is oriented toward the object's content.

Every OpenACS object has a "context," which consists of its position in the site hierarchy. Most objects also have an attribute that could be used to identify it unequivocally, based on its "content." For instance, every bug in bug-tracker has a bug number. The URL to bug #20 should simply be "". Each forum could be given a "name", such as what edit-this-page has for each page. So the OpenACS Q&A forum could be Each forum message could be numbered starting with #1, as qmail does with its mailing lists (ezmlm), so the first message in the Q&A forum would be

The advantage of doing this is not just to make a pretty URL for the user, but to make the public interface not depend on the underlying architecture. If I move my site to another installation, I shouldn't have to go through and fix all of the internal URLs to objects on my system -- not to mention breaking all of the outside world's links to my objects! In the case of file-storage currently (4.6.3), I have to fix URLs every time I upload a new revision, if I want to link directly to the most recent revision and not to the page that shows all of the revisions for the individual file. It would seem to be beneficial all around to ask every package to provide an "abstract" public interface like this.

#2. Extend Content Repository to use the File-System and CVS, rather than the Database, for content storage, if so desired, and put the resulting files in a hierarchy under www.

The metadata for each object would still be held in the content-repository, and perhaps the text-only content of the "live" version (for search purposes). But the option should exist to keep content objects themselves in the file system, in their "apparent" hierarchy, and to control the whole thing by CVS. This should integrate fully with the established standards such as use of the Content Repository. For some types of content (a community software development project, for instance!), this is a more practical way of storing things.

Just today, I discovered that File Manager package tries to integrate with CVS. It looks like dusting that off, and rebuilding it to use the Content Repository (and more fully use CVS), would be a step in the right direction. I want it enough that, if I can, I will do it; and if so I'll contribute the code.

#3. OACSH -- OpenACS Shell

It would be very useful, for trying things out and getting a feel for how the architecture is put together, to have a web-based "shell," by which a site administrator could executive arbitrary Tcl statements or SQL queries, and see the results in the browser. This might also prove to be a good administrative tool. I almost didn't mention this one, because it would seem to be pretty easy to implement (just eval whatever is input into the textbox, and return the result to the same page). Needless to say, this capability, while useful for the administrator, would have to be kept under lock and key (admin login should use SSL anyway, right?).


Okay, those are my "three wishes." I don't expect any OpenACS developers to be a genie, but I appreciate greatly all of the hard work and effort that has gone into making this such an outstanding system.

If I could add one more desire, it would be:

#4. Catch all database errors and display a meaningful error message that nevertheless shows the site template for that context.

It's unnerving to me when something doesn't work and I get a database error. Even if something is "not a query returning rows," it should display the site template and context in which the error occurred, and then within that framework a friendly error message, with full technical details below. This would help the occurrence of an error be more acceptable to the end user. It would also make me more comfortable publishing a site, because even if errors occur I know they will be tried, caught, and sentenced.

Okay, those are my newbie musings. Thanks for listening (since you've read this far!).

Take care,


i've asked about your first point also.

the problems i arrived at are towards the bottom.

related --

I've asked exactly your point #2 (today in fact) about using file-storage to manage the filesystem.  i'm very interested in what you come up with, and am also willing to work on it.

Posted by Dave Bauer on
Derek and Shawn

THe content repository can store files in the filesystem. Besides that, you can write a CR application that publishes the live content merged with a template under the page root.

I am not sure of the advantages of using CVS to manage the content.

File storage content for postgresql, at least, is already stored in the filesystem under openacs-4/content-repository-files. This actually stores all the revisions under this hierarchy. Its transparent to the user of the site and the developer where the content is stored.

About content based URLs, this is also a good idea. I already wrote a very short index.vuh to be added to file-storage that will present files under the folder hierarchy with their filename, and will not require a revision_id. It always serves the live revision of an item. It can be made to also serve other revisions to file owners with an optional revision_id parameter.

This is a fairly straighforward thing to implement for most packages.

Posted by Sean Harrison on

Thanks for the link to your previous message thread. I had missed that one. I especially enjoyed looking around the site that Dirk mentioned -- now I'm understanding why /o/objectid is a good capability -- so much faster than looking up all kinds of URLs, for dynamic pages like Clasohm's whats-new page (I really like that he's showing the item class in parens next to the URLs).

For awhile there I thought Clasholm had implemented another idea I've toyed with, which is dynamic hierarchies based on object categories. Basic idea: type If items exist in the database with that category and subcategory, they'll show up in a dynamically-generated list (probably with the /o/id syntax in the URLs, to be fast). If only one item is there, it'll come up itself.

I think the big problem with using the file system is, how to integrate with Content-Repository _and_ CVS, without making a big hairy mess? I guess that's what I'm going to be thinking about for awhile.

I've set up a project space for this file-manager thing -- just a simple edit-this-page affair: Anyone who registers can edit pages there. I would welcome your thoughts and interactions.

Thanks again,

Posted by Talli Somekh on
Shawn, we already basically did this for a CMS based on OpenACS 3.2.5. It worked pretty nicely, and you can download the code here

That being said, it's pretty unclear on what you're gaining from this that you wouldn't get from proper use of the CR. No one will really stop you since it would be an interesting project, but this sort of jumped out at me:

Use the database for metadata about the files. Model the object system on the OpenACS object model.

Why not just use the object system in the first place?

Further, since you're calling this a "poor man's webdav" why not just use the webdav code that is being built, which you can read about here?

There are some good ideas, but the project seems to dangerously replicate a lot of previous work...


Posted by Sean Harrison on
Dave and Talli,

I agree that replicating previous work is a bad idea. Not only is it a waste of time, but you end up with a square wheel to ride on.

I didn't mean to imply that I wouldn't use the OpenACS object model. (Talli, is the quote you pulled from my website? I'm afraid I didn't fully edit that -- it originally referred to a possible project that cannot be done in OpenACS. Sorry for the confusion.) I also don't mean to say I wouldn't use the Content Repository. Both of those things are at the core of OACS, and the idea is to build on them. I understand and embrace that.

But what I am after is to have the live version of the content always resident on the file system, arranged to match the file hierarchy that the Content Repository contains.

I think this implies modifying the way Content Repository stores files when it is using the file-system. Rather than putting everything in a single directory, it would use a file hierarchy that mirrors the internal structure of the repository. For example, the root of the content repository could be the www directory, and all the content arranged therein.

Why do that? All kinds of reasons.

The current OpenACS involves a large degree of abstraction between the web environment and the operating system. I would like to explore the ramifications of tying the two systems closer to each other, rather than isolating them from each other.

The idea of a merged static dump from the database is intriguing. If you do that when you publish a file, then change the templates, you'd have to go back through and re-dump the whole CR. Right? That would be useful for periodically mirroring the site onto a static webserver.

Re/CVS: I agree, the Content Repository keeps revisions in the database. Perhaps this can serve as a replacement for CVS? Nevertheless, some types of projects would like to use CVS itself, with its file-system storage.

Why not use webDAV? No reason not to. When it's ready, it'll fit right in.

The existence of the File-Manager and the Version-Control applications in the OpenACS toolkit suggests to me that others have found these capabilities useful as well. I think what I'm really proposing is to find a way to combine these applications with the use of the Content Repository and the OpenACS object model, in order to better integrate with the existing OpenACS system, while at the same time providing a way for OpenACS users to make use of the file system on their site, when they have reason to do so.

I'm also interested in having the Content Repository use the file system only for certain sections of the site. Perhaps the way to do that would be to specify, when creating a new CR "root" directory, whether that hierarchy will be kept in the DB or in the file system.

Okay, time to call it a night (er, morning). Thanks for stimulating further thoughts and for making sure I don't fall into typically traps---I appreciate both of you taking the time. Take care,


Posted by Ola Hansson on
Hi Dave,

In what areas is the index.vuh you will add to File Storage different from the one I recently added under /view/ as a complement to the original one under /download/, and which is currently in 5.0 HEAD?

(The index.vuh file I added under /view/ is an almost exact copy of the "CR-generic" one under /acs-content-repository/ which uses a fixed version of "content::init" which enables "pretty URLs" and an easy way to template content items/types in general)


Answering to the original Joel's question, after reading other community members answers I have only one point to add, i.e. SOAP integration, but I'm very, very surprised that no one else perceives this as a problem.

Apart from running the OpenACS native applications, to be really eligible as a portal framework, we absolutely need the ability to cooperate with the existing applications and now I hardly see any alternative to using SOAP.

In fact I'm already using it thanks to the excellent William Byrne's soap-gateway package, but it is unofficial, not even loaded in contrib and lacking the client stubs. Furthermore it uses internally ns_xml instead of tdom and has some limitations with respect to WSDL generation.

For my own use I created the client stubs and adjusted the WSDL generation to my needs, but I think that this is a matter better suited for the core team.

Posted by Dave Bauer on

Oh, I'll look at that. Why is in under /view?

That just again abstracts the problem. The files should have always been exposed as suchL

I'll look at your code, and probably move it into the package pageroot. I can't see any reason to have to add a special /view element to the URL.

Posted by Ola Hansson on
I put the index.vuh under "/view" because "/" holds an index.tcl/adp pair already and "/download" was taken 😊

I'm not sure I understand which problem it abstracts; in what way is the extra folder a problem? (Of course, it would be neat if you could get rid of it.)

Our main concern was to get relative linking to work, which had the positive side effect that it introduced (relatively) pretty URLs.

Posted by Dave Bauer on

I see, you can't have an index.tcl with an index.xql and an index.vuh with a different index.xql.

That is a small problem.

What is the difference between view and download?

My main goal was to get rid of the download directory.

Besides prettiness, stable URLs are one of the most requested features.

Posted by Ola Hansson on

I recently explained the difference between view and download in this posting:



Posted by Ola Hansson on
I think I finally see what you want to do, Dave.

You will merge the "folder chunk" (index page) and the /view/index.vuh functionality into one index.vuh and put it under /, right? That would be brilliant!

It should probably be easy to make content::init "return" any version of a file, not just the live one, if "?version_id=xxxx" was appended to the item's path (I don't think it works like that right now).

That way versions could be templated, too, and we could stop linking toward the /download (or /view) folder - both on the main page and on the "view details" page - and link to / instead.

Too bad this UI change won't make it in time for the 5.0 release (or will it?) ...


Posted by Don Baccus on
Shawn - if you publish content from the CR it does land in the file system much as you suggest.  Now, the publication model has had problems (bugs) and issues (more bugs) in the past and perhaps today but the general notion is that by publishing the content + template into the file system, serving it only requires the file look up and template processing rather than the database hit required to serve unpublished content from the CR.
Posted by Sean Harrison on

Is there an application that publishes content-repository content, so that I can see this in action? I'll install the CMS if that's the only way to do it.

Also -- I understand the idea of merging content with templates, but why is that necessary? The ACS-templating docs tell me that templating doesn't require the database at all. So you can publish the content directly and still get templating, without the database hit. It seems to me much preferable to get the content directly, perhaps with its metadata in an accompanying XML file.

Take care,

Posted by Jun Yamog on
This is getting OT.

Yes you can do a publish of content and make the content a adp file.  That way you can make use of ATS.  I do something similar.  CMS has its own way of merging the template and content.  What I do is publish template to the file system and make use of ad_return_template to the template like traditional way of getting the template.

Merging the template and content on publish also opens up the problem of updating the correct pages.  Not just one.  For example in my template I have a "Lastest Article" box.  If we publish the template + content.  Then each time I publish an article, I must also rewrite the files affected.  Which maybe like site wide, depends on where the "Lastest Article" box appears.  Move and delete also presents additional steps to sync db and file system.

Maybe we should start another thread?

Posted by Dave Bauer on
Discussion of publishing content to the filesystem moved to
53: Re: OACSH (response to 36)
Posted by Nis Jørgensen on
I am a newbie too, and I just wrote two pages which do exactly what you suggest (textbox to input tcl/sql, return result to browser). Here's the one for tcl (the sql one I am not happy with yet):

ad_page_contract {
  @Author Nis Jorgensen
} {
  {script:optional {}}
  } -properties {

if {!is_sitewide_admin_p} {

set result ""

ad_form -form {
      {label {Input tcl_script}}
      {html {cols 80 rows 10}}
  } -on_submit {
    if {[catch {set result [uplevel $script]}]} {
      global errorInfo
      set result "ERROR:\n$errorInfo"

Claudio, in case you hadn't seen it, there has been more XML-RPC and/or SOAP work going on lately. At least Vinod's XML-RPC package will eventually become part of the OpenACS toolkit proper, I bet.
Posted by tammy m on
more newbie wishes...

  • OpenACS-in-a-box install
  • clear,concise,proven upgrade processes between oacs versions for production websites
  • equivalent of aD DevCamps for OACS newbies
  • CR + CMS
  • AOLServer 4.0
  • tcl library friendliness
  • ways to encourage newbie collaboration and involvement (mentoring, extreme-programming-like partnerships?)
Hi Tammy, let me make a few annotations to your requests:
  • OpenACS in-a-box install: Björn Kiesbye has been working on a Knoppix CD running OpenACS. This should be helpful for testing it out. I'm no utterly aware if it is easily possible to install this, but yes, why not.
  • Someone made .deb files for 3.2.5. Is there any chance, we could get them for OpenACS 5.0 / .LRN 2.0 / AOLserver 4? (Read: Would the one having done them be willing to make it again)
  • Upgrade processes are a big thing for the new release as a lot of sites have to deal with this problem. Always keep in mind though, that you won't be able to upgrade easily if you made custom ammendments.
  • aD Bootcamps: Azri ran one internally in India, a bunch of people are talking about having one run in Germany early next year. Once we are a little bit clearer, I'll make an announcement. I utterly agree with you there and it is on my agenda as part of the ongoing process to promote OpenACS to developers.
  • I use AOLserver4 without problems. I created yet another installation instruction (for OS X, that works 100% the same under Linux) which I'm not putting up on the web as of now, but will discuss with the maintainers of the official document to get my ammendments in there. It is using AOLserver 4 (out of CVS) and has no problems with tDOM (package require and such). Kudos to Vinod for the tip.
  • At Azri we have been thinking about asking senior developers for mentoring on pro-bono work for OpenACS. Basic idea would be to put a "more than worker bee" task up, find a newbie interested in doing it and guiding him/her on his task, check the CVS commit logs, be available for questions, stuff like that. For obvious reasons, it is not an easy thing to do, as most of the experienced developers are already swamped with client work.... And yes, the order could be changed (Newbie looks for senior developer for his idea on how to improve the toolkit).
Posted by Dave Bauer on
Getting people to commit to mentoring might be tricky. Until we can figure out a process for that, try visting the irc channel. There is usually somewhere there who is willing to answer questions. For information on the irc channel see

Asking the right questions definitely helps. See How to Ask Questions the Smart Way

Posted by Randy O'Meara on

There's another thread ( where I proposed the collection of AS4 installation notes. I think that's an appropriate place to post your docs for now. Would you mind?


59: Re: OACSH (response to 53)
Posted by Jade Rubick on
I took Nis' page and improved it a bit. Here it is, for posterity:



<formtemplate id="add-edit" style="standard-lars"></formtemplate>
ad_page_contract {
    @author Nis Jorgensen
} {
    {script:optional {}}
} -properties {

set user_id [ad_maybe_redirect_for_registration]

if {![string equal $user_id 298]} {

set result ""

if {[info exists script]} {
    set script [ad_quotehtml $script]

ad_form -name add_edit -form {
        {label {Input tcl_script}}
        {html {cols 80 rows 10}}
} -on_submit {
    if {[catch {set result [uplevel $script]}]} {
        global errorInfo
        set result "ERROR:
" } } ad_return_template
Posted by Glenn Cadman on

OK; Here is my opinion :- Maybe I am being tough but just accept it as "tough love". First of all most people are not coders and many people who may be interested in what OpenAcs has to offer have never wrote compiled a line of code in there life.

New Install HELL

As someone newish to OpenACS, I say it is very very tough to get from a bare bones system to running web services.

For OpenACS to succeed it is critcal to build up a critcal mass of users/developers, I guess too many new people give u saying "Yes it looks good, yes it nice, but I couldn't compile it, so I am now using mySQL and php". I took me 2 nights to work thru all the problems. You need an installer application that can get a Linux system from zero to running by a person who doesnt have a clue about the tools of a developer, Make, emacs and error.h files. It was no problem for me to get a php,postgres, apache system up running...yes I know this is comparing apples to oranges, but it was no problem, openacs fails because the newbie "get it going" hurdle is set too high.

Post Install "Where do I go from here", "how does that work" Confusion

After installation you should have "standard" web site showing off the great features the OpenAcs. I would prefer start with a fully installed system of all standard packages, then tailor them to my sites requirements. Gosh I shouldn't need to be looking at code to work out how to get the "FAQ" to work.

Finally I cannot help with this work as I dont know enough to be productive. But if the forum whish can retask a PC server (1GB*1GHZ*80GB) connected to 24*7 100MB/sec internet link to this work to develop such a "running start" openacs standard site.

BTW any comercial companies using OpenACS, could they offer a bug kill "bounty" system to time rich, money poor home developers/students from 3rd world countries like Australia to kill the bugs holding OpenACS 5 back? Kill a bug get $50, build functionally y get $100?

Posted by Jade Rubick on
Great feedback Glenn. We're working on the issues you've brought up, but I agree that the barrier to getting up and running is one of our biggest problems.

There is an experimental auto-install process now. Eventually, it should be a very easy matter to get your system up and running.

Posted by Nima Mazloumi on
Hi everybody,

As a newbie - I think one aspect is most important for a growing and vivid community:

- a good documentation for admins, users, developers

And this is what OpenACS really needs to meet different groups and expectations. The first (for admins) to make OpenACS competitive with other platforms , that last (developers) to have enough contributors and maintainers for the platform. My suggestion is to have a steadily increasing Coding Best Practice Repository with lots of little articles on how to do this and that. This could be a starting point for folks who want to participate.

We could create such a repository by first consolidating existing contributions of  Philipp Greenspan, Joel Aufrecht, Reuven Lerner, Jade Rubick and the many others (if they are willing to contribute). Everybody should be able to post some little code on how to achieve something.

What do you think?


Posted by Jade Rubick on
Nima, I think that is the plan, really.

When the site is moved to OpenACS 5, we'll be able to use Dave's Wiki code. I personally plan on moving all of my articles and notes to the site (if the webmasters plan on putting up a Wiki -- I do believe that is the plan), and I'll also be active on organizing any content there. I think that will take us a quantum leap forward with developer-supplied documentation.

The documentation team does a great job, but making it that easy to contribute will greatly increase the amount of documenation available. And we can copy a lot of stuff into the Wiki, I think.

I can't agree more with Nima. If I have to choose _one thing_ that is absolutely important for OpenACS, it is good documentation. As a guy who programmed in Java before, I feel terribly frustrated that I can't find the right documentation for the problem I want to solve in oacs. Any serious open-source effort _needs_ to be well documented. As a person who is more comfortable with learning things by myself, I find it uncomfortable that I have to ask my senior colleagues for every small thing that I want to do. This has to change. If oacs has to be seen as 'developer-friendly', more tutorials, more thorough documentation has to be in place. I know it's asking for a lot, but if OpenACS needs to be taken seriously, I guess there is no other option.


Posted by Torben Brosten on
As a person who is more comfortable with learning things by myself, I find it uncomfortable that I have to ask.. for every small thing that I want to do.

Vamsee, I am with you and Nima on this. Progress continues, albeit slowly from the external perspective. Joel Aufrecht (and others) have done well with improving the install docs. I think there are plans for a general documentation wiki or content repository with revision control to be implemented on the next upgrade.

Do post your questions in the QA Forum. The threads provide content that help shape future documentation etc.

Posted by Torben Brosten on
Oops. I see Jade answered above. I look forward to sharing my drafts on, too.

Just a quick comment on the move to Aolserver 4.0.

For those who use nsunix and nsvhr to support virtual host re-direction with full logging capability (that Jerry Asher patched for AOLserver ad33.13) a move to AOLserver 4.0 could potentially be bad news if compatibility with ad33.13 was not maintained.

Sourceforge has nsvhr and nsunix listed and the most recent mods seem to be about a year old - so it might work. I will have to test it with version 4.0 and post the result.

I see that Jerry's site is not around any more which is a great shame because his instructions were fantastic - though google has the cached versions for now. The following post refers to Jerry's document but the link is now dead. Perhaps Jerry and Jade would be willing to put this up on Jade's article repository . It would be a shame to lose that work.

Posted by Nima Mazloumi on

I would like to add some thoughts that IMO are important to make dotLRN the leading open source learning management system (plus the reasons):

  • Easy installer for linux distributions like SuSE. I don't think RedHat is interested but now that Novel and SuSE merged SuSE will become very strong not only in Europe but also in the US.
  • A SCORM Runtime Environment (1.2 or even better 1.3). As a good starting point we could go with the client-side libraries shipped out with the ADLNet SampleRTE if licensing allows this approach. Thus the API adapter on the server-side has to be reimplemented in OpenACS.
  • An extended/improved gatekeeper module for integrating external web-based applications like: SquirrelMail, Horde-IMP, Wiki, University Libraries or any other service that uses the same user accounts. The gatekeeper should be able to produce valid html/xhtml, forward session and cookie info, check if source is compressed data or not, allow usage of master-template (this feature already exists), a better rewrite proc, keep a registry for single-sign-on feature...

    This package is a small but powerful feature due to it's integration qualities. I tested it with different sites from static html to php-based applications. It works even with frames. Now - this is very interesting - when I tried to spread the news about dotLRN at our university the number one question was: Can we easily integrate our web stuff and make use of the dotLRN access control and packages. The answer: yes! Run a local apache+PHP+mysql installation with the AOLServer as its only client and voilá.
  • A wiki based documentation system for users, developers and administrators - complete and open to registered users with version control. There are many valuable info scattered in the forum threads which could be aggregated in wiki pages. We could either create our own package or integrate with existing. c't 25 from 1st. Dec. 2003 made an excellent comparison of available wikis:
    1. MediaWiki (PHP-MySQL) - 68,65 % >20 languages, no CamelCase, very strong in scalability and usability, weak in documentation, relatively easy to install
    2. MoinMoin (Python-Text) - 1,75 % 8 languages, CamelCase, very strong in documentation and usability, weak in scalabilty
    3. PhpWiki (PHP, GDBM, MySQL, PostgreSQL...) - 1,59 % 7 languages, CamelCase, weak in documentation, strong in backend binding
    4. Twiki (Perl, RCS) - 4,49 % English only, CamelCase, very strong in documentation and plugins, weak in usability and scalability, most popular for intranets
    5. UseModWiki (Perl, proprietary format) - 16,32 % 18 languages, average, extremely easy installer
  • Migration to latest AOLServer and PostgreSQL
  • A consistent UI. There are UI changes (package-2-package) and (package-2-core). Also if we want to make use of the gatekeeper module with a master-template we need to have a unique CSS. Otherwise external designs will mess ours up. I tried it and it's a mess.
  • Extended File Storage module so that the administrator can decide between the options to store files into database of with OpenAFS. Advantage: User can access and share owned files over IMAP, SSH and other usefull services.

Merry X-mas and happy new year,
Nima Mazloumi


_A SCORM Runtime Environment (1.2 or even better 1.3). As a good starting point we could go with the client-side libraries shipped out with the ADLNet SampleRTE if licensing allows this approach. Thus the API adapter on the server-side has to be reimplemented in OpenACS._

As part of the implementation of SCORM on oacs, we did implement an SCORM Runtime Environment (according to 1.2).

Adam Ullman was the man behind it:

This RTE will be integrated with the other IMS standards by the end of January.