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

- Object orientation - each object type should have a predefined set of Tcl methods such as ::create, ::get, ::edit, ::delete, ::render, ::list, ::rss_feed etc. We might want to consider using an object oriented variant of Tcl (such as incr Tcl or XOTcl).

- We want to reduce the usage of PL/SQL code so most procedural logic for OpenACS objects will be in Tcl code. This will speed up development, reduce code duplication and ease upgrades.

- We want to auto generate SQL for the standard cases and leave escape routes for the more complicated ones. This means there will be a way for package developers to manually write SQL queries when they need to. Reasons for using manually written queries may be that the SQL generator cannot provide the data set needed or because its SQL is not performant enough.

- Object services such as ratings are not object type attributes and typically apply to all visible objects in the sytem. We would like to see Jeff's KMS system with its object services integrated as soon as possible.

- We want our view templates (such as blog view, calendar view, list view etc.) to be object type agnostic so that the website admin can mix and match views with object data as he pleases. For example the blog view may require a data source with the attributes subject, body, date and author but it doesn't dictate this data to belong to a specific object type (i.e. the blog view can list other things than blog postings, such as photos). A data source can draw its data from one or multiple data types. We are missing input contracts for adp:s. We need to converge the form builder, ad_page_contract etc. data types. Challenge - do we want sortability to be in the view/datasource contract?

- Challenge - how do we maintain state for portlets while avoiding URL name collisions? For example suppose you have two blog portlets on a page you then want to be able to change the sorting of one of the portlets without affecting the other portlet.

- Request processing. We could mount objects of any type in the site map if the objects know how to render themselves.

- We would like to provide an admin interface (a CMS backend) where interaction designer draws up page flow and wire frames, the designer designs the pages

- Portlets take a set of parameters and uses a certain adp (view) and Tcl (datasource) template. Portlets register themselves with the portal system so that they are available for selection by the page builder in the page admin UI. To make working portals more attractive and worthwhile we need more high quality look and feel options (using CSS) and a better portal UI (we can look at services like TypePad for ideas).

- Caching of portlets should ideally be done at the package level since the package knows when its data has changed and the view cache needs to be flushed. The portal system cannot easily know when to cache. We need a good way to cache adp output. The fact that different users have different view permissions makes caching of object listings very difficult. If all listed objects share the same parent the permission caching problem can be circumvented if instead of checkig read permission on every single object we only check read permision on the parent of the objects.

- For scalability the database tends to become the ultimate bottleneck since you can always add more frontend web servers. Multiple web servers has the drawback that caching becomes more difficult.

- Page rendering. Content management systems (Typo3, Plone etc.) have a backend with a page tree that allows Interaction and Graphic designers define pages, layouts and links between pages. Implementing this on OpenACS may not require changing the request processor. The page map could be defined in an XML file in the filesystem.

The tcl functions listed above are interesting. What I'd like to see also is ::putxml and ::getxml for objects. That would make it easier to transport objects via xml and files (or http) and still allow for creating the initial objects via xml and files. I think this would solve what I see as some of the current conflict in ACS. It wants to be a dynamic system that allows users to add attributes to object via a web interface and everything automagically works, yet nothing quite works that way because the initial overhead is high because there is no way to easily create the objects required and transport them around.

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

You would make creating an object type declaratory and the requisite tables, plpgsql, and views would be created from that (and lest anyone think this is to ambitious I would point out the CR already implements exactly this but only for CR derived object types).

It would be very nice to have a standard set of SQL and TCL routines for every object type. I also like the idea of auto generating them because it ensures they are there and they they consistantly do the same thing. I think having an object::init function for custom logic would be nice for objects that need that.

It seems ACS is being pulled in a couple different directions. At first it valued SQL and scalability. Now it seems headed for customization rapid development and database portablity. I personally prefer the later. Scaling can generally be solved with hardware/tuning and hardware is pretty cheap these days. I also think if you could customize without hacking the code upgrading would be alot easier.

Sorry did not mean to have a negative discussion.  Just would like to point out some of the possible pitfalls of some items.

I think having create, edit, etc. standard manipulators is good and helpful.  I would lean on having default routines if those methods are not overridden instead of auto generated routines. I guess there are the very similar.  I would lean on the pregenerated methods be not easily visible by the developers and that you need to create overrides rather than editing existing pregenerated methods to override.  So in order to override a standard method you create rather than edit existing auto generated standard methods.

However, you OpenACS gurus who will be designing most of this stuff, please keep in mind all the discussions and reported problems with that other recent rapid development tool - ad_form.

Historically, the switch from OpenACS 3.x to 4.x seems to have given substantial additional power at the cost of a moderate increase in complexity and decrease in development speed. (And from what I've heard from those who've actually used it, ACS 5 Java probably gave a huge increase in complexity and a great decrease in development speed, for nebulous or un-realizable increases in power. Last I heard anyway; perhaps it has improved since then.)

If OpenACS 6.x could improve on the power of OpenACS 4.x and 5.x while beating the rapid development and short learning curve of OpenACS 3.x, that would really be slick. Given what others have talked about here, I suspect it can be done, too.

As for "improving the power", I don't see any mention of Lars' "object soup" ideas. What happened with that one? Was it discarded as a bad idea, tabled for later discussion for a later version, or?

Also, Peter's original list above doesn't seem to have "best of breed Content Management toolkit" on it at all. I find that surprising, given all the past discussion of how hugely useful it would be to dig out all the existing almost-never-used OpenACS Content Management functionality and re-factor it into one cohesive, integral, widely used whole.