Forum OpenACS Q&A: new ACS versions

1: new ACS versions

Posted by Paul Doerwald on 03/01/00 10:26 PM

I'm curious what happens when a new ACS version is released. Will you
diff new ACS versions to make them work with Postgres, or is this a
complete fork?

The idea of using postgres is very attractive, but I'd like to be able
to stay up to date with the main ACS.

I'm just wondering how you've addressed this problem.

Paul.

2: Response to new ACS versions (response to 1)

Posted by Ben Adida on 03/01/00 10:30 PM

A very good question. Right now, we're planning on merging diffs as best we can into the tree. However, we think the ACS can be vastly improved. We're not talking number of features or number of modules (although that, too, can be improved). We're talking about the core structure, the modularity, the ability to easily extend it without stepping on other people's toes.

Starting in April, which is when we hope to come out of beta, unless the ACS/Oracle becomes much more modular, we're going to branch. We'll still try to keep up with features, but we have no reason to keep up with the actual code.

Please comment on this, though, we want to hear what the community thinks.

3: Response to new ACS versions (response to 1)

Posted by Paul Doerwald on 03/01/00 10:38 PM

It's a pain to redo work that's already been done. If only Ars Digita would incorporate postgres into their dev tree with some ifdefs for when they build the distro package. The community could maintain the postgres version, and they could maintain the oracle version. That way the community would never be out functionality.

Somehow, though, I doubt that will happen.

The difference is that they've got a team of paid programmers working on the software all the time. ACS/pg has volunteers. Volunteers can do great things (Linux, etc), but there's a strength in paid programmers, especially when they're churning out greatly enhanced new releases once a month.

A complete fork would be sad, IMHO.

If we look at the past 'n' versions of the ACS, how much do existing modules change in functionality? If they don't change, or change little, then a 'diff' repository of some sort would work on new ACS releases, and the only porting work would involve new or in-development modules.

4: Response to new ACS versions (response to 1)

Posted by Ben Adida on 03/01/00 10:45 PM

We already did a merge between 3.0 and 3.1 because we got behind on 3.0. Don Baccus can tell you that it was relatively painful, because the change in all the SQL queries screws up diff/patch.

What would be VERY helpful is a complete abstraction of all the SQL queries. So Lobby ArsDigita to start modularizing things a little better :)

Don't underestimate the community's interest in a fully open-sourced ACS solution...

5: Response to new ACS versions (response to 1)

Posted by Ben Adida on 03/02/00 04:18 AM

Here's an interesting additional bit of info: ACS 3.1.4 just came out today, and in 15 minutes I merged the changes into our code. Only 0.0.x change, but still pretty good merge-ability so far.

6: Response to new ACS versions (response to 1)

Posted by Paul Doerwald on 03/02/00 04:54 AM

15 minutes.. That's not too bad!

I don't know what good lobbying AD to add an SQL abstraction layer would do. They're already trying to reduce abstraction as much as possible. Another layer goes against everything philg believes in.

Has Philip/AD offered anything in the way of AD programming standards that you can count on in the way of easily diffing? If they can guarantee a certain amount of stability in the way they program the core software, porting to postgres could be quite simple...? (or am I way off here...?)

7: Response to new ACS versions (response to 1)

Posted by Ben Adida on 03/02/00 05:17 AM

ArsDigita is not sticking to any standard of backwards compatibility. They try to provide conversion scripts for data models, but that's all. I can't say I disagree with their approach: they don't want to be tied down by any legacy code.

of course, for ACS/pg's sake, this isn't so great, but we'll do what we can.

8: Response to new ACS versions (response to 1)

Posted by Ken Chakiris on 04/05/00 06:43 PM

I think we should concentrate on stabilizing at a fixed ASC version number and make the code as bug free and easy to understand as possible. After looking at the code for a while I think that ASC needs some refactoring - that is to say making the code easier to understand without changing the functionality.

The navigation scheme also needs some improvement. Hence, I think we will need to fork the code at some point.

9: Response to new ACS versions (response to 1)

Posted by Ben Adida on 04/05/00 06:49 PM

Well, we're going to stick with ACS improvements as long as that doesn't handicap us too much. Reworking the ACS is a tremendously large task, and I would hate to fork and then see our project die because we don't have the resources to duplicate ACS/Oracle features. I think it's something to consider, just not lightly.

10: Response to new ACS versions (response to 1)

Posted by Ken Chakiris on 04/05/00 08:30 PM

Probably you are right that forking the code is not such a good idea. Perhaps as I get used to the ACS way of doing things the code will seem less messy.

However, and this my be ACS/pg's goal also, I have a greater interest in having a stable production quality system then staying current with the latest ACS version.

11: Response to new ACS versions (response to 1)

Posted by Roberto Mello on 04/06/00 01:18 AM

Besides the reasons that Ben already mentioned for not forking the code (I don't think it's a good idea either), aD is revamping the templating and navigation system for the upcoming ACS 4.0 release.