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

Collapse
Posted by Torben Brosten on
I learned much from aD's way and still think that something like it could work now, if only founding principles would include rejecting external investments to the company --investers could almost as easily invest in a project that uses the company resources instead.

Part of the aD way, included having two sw developers per package, which helped increase documenting in code etc.  Are there two package keepers for each Openacs package now? If not, maybe efforts should be made to increase participation?

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)