At first it valued SQL and scalability. Now it seems headed for
customization rapid development and database portability.
In my opinion, OpenACS has always highly valued all of those things,
and there is no inherent conflict between them, either. It's only a
question of what areas people currently want to put effort into
improving.
Scaling can generally be solved with hardware/tuning
Barry, that's a statement with basically null meaning. First of all,
scaling is very much
not "generally" solvable by hardware.
(Lousy software and lousy queries can easily trump all hardware.)
Secondly, many folks have hacked on pieces of OpenACS over the years
to make it scale (permissions in particular come to mind), and that's
precisely what "tuning" is!
So yes, scaling can generally be solved, somehow. But doing so is
not necessarily easy, and it's far, far better that that
solving go into the standard toolkit, rather than every high-volume
OpenACS site having to fix it all themselves. The only reason getting
an OpenACS site to scale reasonably well today is reasonably easy, is
because of all the scalability work that has already gone
into the toolkit.
