Forum OpenACS Q&A: new ACS versions
diff new ACS versions to make them work with Postgres, or is this a
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.
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.
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.
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...
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...?)
of course, for ACS/pg's sake, this isn't so great, but we'll do what we can.
The navigation scheme also needs some improvement. Hence, I think we will need to fork the code at some point.
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.