Forum OpenACS Development: ACS Compatibility?

1: ACS Compatibility?

Posted by Mike Bruce on 04/04/01 09:05 PM

OpenACS is always referred to as a "port" of the official ACS. Going forward, is this going to remain the case?

Is OpenACS going to keep following aD's releases, or is this going to in effect fork at some point? There are two related reasons I'm asking this question. The first is that we keep hearing that aD is going all Java in the future. The second is that there are many features that could be added and changes that could be made to the ACS to make it better.

So, is OpenACS interested in remaining compatible with a possibly abandoned version of the ACS, or is it going to move forward independant of aD's future development?

2: Response to ACS Compatibility? (response to 1)

Posted by Ben Adida on 04/04/01 09:30 PM

OpenACS is not going to be a "port" for very long. OpenACS 4 is a superset of ACS 4, in that it will run on Oracle *and* on PostgreSQL. We will certainly improve OpenACS 4 as we see fit, given that ACS Classic Tcl is, for all intents and purposes, dead.

Now, the question is: how much do we need to improve it? There are some things like the content repository that we'd like to improve. The core OpenACS team will probably handle that task. However, the core OpenACS team is not going to get deeply involved with specific packages like CMS and ecommerce: we're going to let the developer community address those functionality-specific issues.

*That* is the strength of OpenACS 4: developers can add features in a packaged, modular way, without involving the OpenACS core group. Thus, while we see some level of improvement that can be made to the core, the real innovation in OpenACS 4 is going to come from package developers out there... Get PSYCHED, because the spotlight will start shining on package developers within a couple of weeks!

3: Response to ACS Compatibility? (response to 1)

Posted by Don Baccus on 04/04/01 10:38 PM

There are other core issues that will be addressed, i.e. poor performance of the general permissions scheme in particular.

And I'm getting increasingly interested in improving the APM as I work my way through it in order to teach it about multiple databases and the resulting db-specific sets of queryfiles, datamodels, etc.

I'm sure some of us "core OpenACS" folks will actually help in module porting. I think Ben's point is that we don't NEED to help because the modular approach makes it a lot easier to parcel out pieces to independent sets of people. That doesn't mean we won't WANT to help!