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

Collapse
Posted by Barry Books on
The code I was refering to is all the tcl/adp code. My main point was you have to bootstrap the system some how but after that I'd rather have everthing in the database.

It would be very nice to have a standard set of SQL and TCL routines for every object type. I also like the idea of auto generating them because it ensures they are there and they they consistantly do the same thing. I think having an object::init function for custom logic would be nice for objects that need that.

It seems ACS is being pulled in a couple different directions. At first it valued SQL and scalability. Now it seems headed for customization rapid development and database portablity. I personally prefer the later. Scaling can generally be solved with hardware/tuning and hardware is pretty cheap these days. I also think if you could customize without hacking the code upgrading would be alot easier.

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.