Forum OpenACS Development: Re: Notes from OpenACS 6 Design Discussion in Heidelberg

Collapse
Posted by Andrew Piskorski on
At first it valued SQL and scalability. Now it seems headed for customization rapid development and database portablity.
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.