Forum OpenACS Development: Re: Notes from OpenACS 6 Design Discussion in Heidelberg

First of all, we're just trying to have a fruitful discussion on where we collectively want to head. I personally have some ideas, because I've thought a lot about it over the past 6 months, but I'm stilling having trouble articulating it and getting the details sorted out. Which is why I wanted to discuss this in person, which is, to say the least, much easier.

The general idea is to make OpenACS more of what it was intended to be (from OpenACS 4 and forward). Not less.

Also, the idea is obviously to build on what's there.

In a number of places, we have 3-4 half solutions to the roughly the same problem. In this case, the intent is not to do a fourth or fifth half solution, but rather to try and synthesize the existing solutions into one coherent solution.

Now, to some specifics:

Dave: The underlying idea is that if OpenACS is going to be both in the eLearning space, in KM, and in whatever-website-you-happen-to-build-for-your-grand-mom business, then it will have to allow for customizing the user interface. For example, if you have a site that only needs one forum, it should be trivial to get rid of the page listing all forums in a package instance.

Currently that requires manually changing files in the packages/forums/www/ directory, which means you're now going to have trouble upgrading.

Second, the ability of users or superusers to tweak and make changes to the user interface is a major differentiator in the .LRN market. None of the big players support this (for obvious reasons), and everybody is doing it - Heidelberg, Mannheim, Bergen, Vienna, Sloan.

Now, my thinking is that browsing objects in the CR is different from browsing pages in the system. In a traditional CMS system, in the back-end, you'd have one page per news item, for example. In OpenACS, we have one news-item page, and it takes a parameter of which news-item to display. I want to keep things the OpenACS way, because that's what a dynamic web application platform should look like, but I'd like to (a) make it easy for people to customize UI to suit their users, and (b) do so without forking code, and (c) have a back-end UI to help them.

Now, we talked about where to store such a thing, noting that there would be advantages to being able to use version control for this (it's essentially UI development), and Jeff suggested just storing it in a /local directory.

Barry: OpenACS doesn't currently put code in the file system. And there's a trade-off, as you mention. I don't know what the right place to draw the line is.

Jun: A number of us here in the community are painfully aware of the ACS Java experience, and have no intention whatsoever of repeating them.

I'm not sure how you draw that conclusion from what's written, though.

The ::list method mentioned, in my mind, should know how to build the query to get all the desired objects in one query, not get each object through a separate query. You can still choose to develop like you do today, or you can hand-tune the query.

As for moving away from PL/SQL, that was something that came up during the conference. There was broad agreement that PL/SQL is hard and time-consuming to develop and debug, and that it's mostly not necessary at all. You can easily auto-generate it, write the same code in Tcl intead, or write a single API that does it for you. There's no talk of change in functionality, just in choice of programming language.

Yes, some people may abuse the system, but we also have poorly written queries today.

Look at some typical applications like forums, file-storage, blogger, calendar ... There's a lot of code that could be auto-generated.

Of course, as Jeff pointed out, we might not want to make it too easy, we all still want to have jobs ...

/Lars