Forum OpenACS Development: OpenACS 4.0 Status and Timeline

Posted by Bob OConnor on 01/08/01 04:22 PM

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

Thank you.
-Bob

2: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Don Baccus on 01/09/01 11:39 PM

Good timing! Ben and I met with Adam Farkas today at ars Digita to talk about this very subject, and Ben and I are going to spend thursday poring over the data model for 4.1 in order to scope things out in detail, and to begin the process of setting up guidelines for porting things like the PL/SQL packages that implement so much of the basic functionality of the new toolkit.

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 ...

3: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Talli Somekh on 01/12/01 10:44 PM

Great!

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.

Talli

4: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Adam Farkas on 01/12/01 11:02 PM

I'll answer your questions as best I can, based on the meeting that Don, Ben & myself had here in cambridge.

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.

5: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Don Baccus on 01/13/01 02:23 PM

Frankly, I don't think PG 7.1 will be the sticking point here. We'll be working hard on the core (acs-kernel and friends) data model and query porting over the next few weeks. There are a few pieces that need to be written before others can pitch in, i.e. handling "bind" syntax in the PG driver (on my plate) and the query dispatcher (to provide a systematic method for replacing incompatible Oracle queries with their SQL92 or PG equivalents without removing the Oracle queries from the source).

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!

6: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by David Kuczek on 01/13/01 04:21 PM

Is there a roadmap for the porting of the ACS 4.1. core?

7: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Dan Wickstrom on 01/13/01 04:33 PM

Don,

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.

8: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Don Baccus on 01/14/01 04:09 PM

First, thanks for doing the bind variable emulation, I was unaware of
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.

9: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Dan Wickstrom on 01/14/01 10:36 PM

Well it sounds like you already have most of the problems with inheritance covered. Since you're only planning to use it on the acs_objects and derived tables, it sounds like the wasted effort would be small if it didn't work out.

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.

10: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Don Baccus on 01/15/01 06:09 AM

Ben and I talked (I probably talked too much :) and Ben took notes.

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.)

11: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Roberto Mello on 01/16/01 07:57 AM

Hey howdy hey,

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 :)

12: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Adam Farkas on 01/16/01 03:51 PM

Hey Roberto! Good to see you back. We thought you'd been kidnapped, it had been so long since we'd heard from you...

13: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Roberto Mello on 01/16/01 04:39 PM

It's great to be back Adam. It had been a month and three days since my last post here. Ugh!

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).

14: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Don Baccus on 01/17/01 03:58 AM

I finally remembered to test "alter table" with PG 7.1 beta3, and
child tables do get the columns added to their base table by "alter
table" commands.

Cool...

15: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Dan Wickstrom on 01/17/01 03:37 PM

Very cool!

So how is this "query dispatcher" going to work?

16: Response to OpenACS 4.0 Status and Timeline (response to 1)

Posted by Michael Feldstein on 02/01/01 09:55 PM

Any progress on pinning down a timeline yet? Is the CVS on Sourceforge (or elsewhere) set up yet?