Forum OpenACS Development: OpenACS 4.0 Status and Timeline
The latest post on this board seems to be Nov30th. Ok, It was a great holiday season and Russian Christmas ended yesterday. So...
I'd love to see an updated Status and timeline for:
- PostgreSQL 7.1
- OpenACS 4.0
Expect more news in a few days.
PG 7.1 is either in its second Beta (first for the public at large) or will be momentarily, at one point it was going out last Sunday but I think a few more bug fixes are getting shoehorned in at the last minute.
Regardless, it seems in good shape - apparently sourceforge.org is now running on top of a pre-beta version of PG 7.1 ...
It's great news to hear that the OpenACS4 project is starting to pick up steam. I imagine that there will be a relatively detailed announcement at some point, but I'd like to ask some questions that can be answered in this or another forum.
a) Will the next version of OpenACS be based on ACS4.0 or 4.1? From the docs acs40.arsdigita.com, I get the sense that there will be a kind of forking of the 4.X dev branch where the 4.0.X will continue to be supported to some degree but 4.1 will have some additions not compatible with 4.0.X, namely the workflow module. Which version will OpenACS4 be based on?
What I'm basically asking is will OpenACS4.X follow the same life-cycle OpenACS3.X did, namely be a couple of releases behind Classic? This is entirely reasonable given the porting efforts are voluntary, but I'm wondering whether there is a plan for organizing porting efforts so that we can take advantage of benefits implemented in each release?
b)Can/will the kernal/core of the next OpenACS version be published prior to the official release of PG7.1? In other words, I've been a little worried that because OpenACS4.X is tied to PG7.1 we're beholden to that project's release date.
While we all know how exact and precise the world of software engineering is, particularly release schedules, I was wondering whether the release of OpenACS4 needs to follow PG7.1's release.
Of course, if sourceforge is already running on a pre-release system, this question may have been answered.
I have more questions, but will leave those to be asked by people who know more than I.
First, it'll be based off of ACS 4.1. The ACS 4.1 code freeze is tonight, so by tomorrow morning we'll have a stable code base to peruse.
Yes, PG 7.1 will be necessary. Don has worked with 7.1 beta and it is apparently in decent shape. Hopefully he can chime in.
At this point, we have little choice but to have faith in their ability ot adhere to a release schedule. [7.1 has uber-important features, like outer joins, that ease the pain of porting considerably.] That said, I think we can feel reasonably comfortable working from their betas.
I'm very enthusiastic about OpenACS 4.1. PG has made incredible strides in the past several months, and I believe that the community may be on the verge of developing a version of ACS that is -- in many respects -- superior to the Oracle-based version.
I'm also looking into writing some helper functions to make PG's inheritance model more usable for ACS 4x.
After the core's ported, we'll be asking for volunteers to take on individual packages. At that point, it doesn't really matter if PG 7.1's still in beta (it is in beta3 right now, you can pick it up at ftp.postgresql.org, in /pub/dev) as package porting will take some time, too. I'm expecting a mid-Feb or, at worst, an end-Feb production release of PG 7.1 ... that's only 4-6 weeks!
Adam Farkas and aD gave Ben and I a very warm welcome to their offices this week, along with office space for a day, which was greatly appreciated by both of us. Thanks, folks!
I added bind variable emulation to the pg driver a couple of weeks ago. The changes are checked into cvs.
After following the pg-hackers list for quite a while, I wonder if we should really use pg's inheritance feature. Discussions about problems with inheritance seem to always end with a disclaimer from one the developers that goes something like: "Inheritance is not fully and consistently implemented". Searching through the list archives, I've come across the following potential problems:
- Alter table doesn't work correctly on inherited tables.
- Triggers are not inherited (including referential integrity triggers).
- Indexes not inherited.
I understand that the index problem can be worked around by explicitly adding an index to the inherited table, and the alter table problem can be worked around by recreating the tables. Have you looked at this stuff in detail? Are there work-arounds for triggers not being inherited? I've probably not covered everything, so there is a possibility that we might uncover quite a few other problems with inheritance, once we start using it heavily. I'm concerned that we're going to saddle ourselves with alot of problems that affect the performance and consistency of openacs 4.x. Also, I don't think inheritance is high on the pg developers list of priorities, so we probably won't get a quick resolution on inheritance problems.
this and it is a big help.
Regarding inheritance, I was unaware of problems with alter table,
I'll investigate this. If we can't alter table on inherited tables,
we can't use it.
As far as the other stuff goes, I've done a little work investigating
the difficulty of adding a user C routine to find triggers,
constraints, and indices and then issuing SPI calls to create them on
the inherited table. This is now something that is at least feasible
because ACS 4.0 names all constraints in a consistent manner, which
means munging constraint names into something unique based on the
derived table name won't be difficult.
We'd only be using inheritance on acs_objects and derived tables, not
willy-nilly throughout the system.
I don't think performance should be a problem, as selecting from all
inherited tables is in essence a UNION Of simple selects on the table.
This replaces the JOINs needed in the existing ACS Classic 4.0 datamodel.
Interest in inheritance is picking up within the hackers group,
presumably because more and more of SQL92 has been implemented. The
lack of interest has been largely a triage issue, with SQL92
compliance requiring more immediate attention.
Ben and I more or less decided we'd take a shot at trying an
inheritance-based datamodel, and if it appears to be more work than it
is worth, we'll quickly back off and port the datamodel directly.
As far as a timeline goes, Ben's getting started next week. I can't
get started until the week after, though the fact that Dan has done
the bind emulation means my first task is already done (thanks
again!). Dan's starting on the core, too (when, Dan?).
If folks are interested in looking at ACS Classic 4.1's core and a
couple of modules (i.e. bboard) without downloading it themselves, you
can now browse the source via the SDM here at openacs.org.
As far as performance, I was not too concerned about selects from inherited tables, but rather the possibility that indices might not function correctly. Hopefully, your plan will take care of that problem.
I'm ready to start immediately. All we need to do is partition up the work and decide on porting guidelines that are specific to acs 4.x.
Since you and Ben looked at the data-model in detail, did you come up with a new set of porting guidelines for acs 4.x? Generally we already have a pretty decent idea of porting guidelines, but I was wondering if your and Ben's look at the data-model brought to light new issues that we need to address prior to commecing our porting efforts.
He's working on a porting document for discussion. It will get
posted Very Soon, won't it, Ben? I'm eager to let folks have a shot
at it, and will personally either defend or punt on points depending
on group input. I'm certain that Ben has the same attitude.
Given the vast rewriting of the ACS, and the move to a truly modular
approache, it is crucial that we get the core right, be it ugly or
less ugly. An object model recast upon an RDBMS, or even an ORDBMS
with limitations like PG, will be and is - in the case of ACS 4.*
Classic you can read it today - ugly.
The only question is "how ugly".
(I've got to add that the ugliness pays for real gains in modularity,
extensibility, etc. It points to the desirability of working in a
truly useful ORDBMS environment, and hopefully PG will get there in
the next six to twelve months.)
Back from "vacation" in Brazil where I spent most of my time fixing/building/rebuilding family computers for free :) It was nice to get together with them however.
I was delighted to read about the Ben/Don/Adam meeting. I take the same position as Dan: I am ready to start. I am taking less classes this semester and will have more time to help.
Feels great to be back and not have to touch a modem anymore :)
I was following the posts every so often, when I dialed-up from a modem, but not very closely. Now I am back in game :) I have a software engineering project this semester where we'll probably be using OpenACS. It'll be fun. I already setup our SDM package and everything (btw, thanks to Ben and all who worked on SDM).
child tables do get the columns added to their base table by "alter
So how is this "query dispatcher" going to work?