Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Collapse
Posted by Dirk Gomez on

Most packages don't even have one maintainer 😟

Here's a unordered list of wishes I have:

Remove unnecessary layers of abstraction. We are still suffering from the Second System Effect of moving from ACS 3 to ACS 4.

So let's move code back to SQL statements. Especially DotLrn is filled to the brim with such constructs:

Retrieve a list of objects
For each item of this list do
  Get the object's owner's name
  Get the viewer permission record on this object
End for

all this nicely put into procs. Inhibits scalability, more code, more intricate, less readable.

I also wish we would put more intelligence back into the SQL layer. After all that is where we differ from similar toolkits and the fact that we are free to write "arbitrary" SQL statements ensures a reasonably high level of scalability.

No wrapper procs around SQL statements. I was told that I can access an arbitrary SQL statement in an arbitrary XQL file, so why the heck do I need a wrapper proc that does nothing but return a bitstream if I can run the SQL statement directly.

Best practices pages. That could be an ETP page for which we handle write permissions very liberally.

Have peer review by establishing a commit diff mailing list (Raised a bunch of time by myself). That's a light-weight way to enable eletronic programmer collaboration. (I'm willing and available to throw work at this)