Forum OpenACS Development: Re: Re: Re: OACS 6 and beyond

Collapse
Posted by Don Baccus on
I don't want it in 5.3.

1. As Dave and I have discussed 5.3 (though we haven't run it by everyone on the OCT yet), the goal for 5.3 is to have an acs core that passes all automated tests. Getting to this state has been the focus of the last two bug bashes and, since there are still a bunch of failing tests (almost all in the "fails to meet coding standards", not "code doesn't work" category), will be the focus of the August bug bashes, too.

This is a very modest and very focused goal.

As a result, we've discussed branching the code in September, with a release date in October. By our standards, that's light-speed, no time for fancy schmancy stuff.

I'm committed to continuing the release manager role on (presumably, or rather necessarily given the realities of the community) a volunteer basis to get this out in that kind of time frame.

2. It is possible that Neophytos' work is the be-all and end-all of persistence layers that can be developed in Xotcl.

But there's no way I, at least, am open to deciding to settle on a new API that I haven't even seen yet!

Also, to be useful in the ACS model, it needs to deal with object attributes when defining datastructures. We should really be pushing for something along those lines. We have TCL-based code available that does it, adding such a feature to an Xotcl layer would be easy enough.

Though as I said in another post above, taking full advantage requires our finally biting the bullet to clean up the datamodels. Also we really need to be adding attributes to existing objects where folks don't do them if we really want to leverage stuff like being able to build forms and pages directly from the object model (code which exists in the CMS and elsewhere but which has been little used).

And, if we were to adopt a new API such as a persistence level, deploying it without rewriting acs core would just add another level of complexity to the code that newcomers would have to conquer in order to participate. The barrier's already too high with too many competing APIs and programming approaches. Adopting a new API means, I should hope, taking the time to rewrite core packages to actually use it.

Not something that's going to happen this August :)

No, it's more a Oacs 6 thing in my mind.