More and better support for rapid development would be very welcome,
and the specifics Don touches on above mostly sound good to me.
(Except for auto-generation of the SQL DDL for data models; so far I'm
leary of that.) It certainly would be very nice to write PL/SQL only
when you really
want to write PL/SQL, rather than being
forced to do so repeatedly for boilerplate code.
However, you OpenACS gurus who will be designing most of this stuff,
please keep in mind all the discussions and reported problems with
that other recent rapid development tool - ad_form.
Historically, the switch from OpenACS 3.x to 4.x seems to have given
substantial additional power at the cost of a moderate increase in
complexity and decrease in development speed. (And from what I've
heard from those who've actually used it, ACS 5 Java probably gave a
huge increase in complexity and a great decrease in development speed,
for nebulous or un-realizable increases in power. Last I heard
anyway; perhaps it has improved since then.)
If OpenACS 6.x could improve on the power of OpenACS 4.x and 5.x while
beating the rapid development and short learning curve of
OpenACS 3.x, that would really be slick. Given what others
have talked about here, I suspect it can be done, too.
As for "improving the power", I don't see any mention of Lars' "object
soup" ideas. What happened with that one? Was it discarded as a bad
idea, tabled for later discussion for a later version, or?
Also, Peter's original list above doesn't seem to have "best of breed
Content Management toolkit" on it at all. I find that surprising,
given all the past discussion of how hugely useful it would be to dig
out all the existing almost-never-used OpenACS Content Management
functionality and re-factor it into one cohesive, integral, widely
used whole.
