Forum OpenACS Development: Trim Down OpenACS 4.0

The interesting question, of course, is what to trim? What things can get cut out completely or trimmed down? Is it the object model? The content repository? the complicated membership/relations/relational segments data model? The overburdened request processor?

Or are you thinking simpler things like cleaning up navigation-procs, utilities-procs, etc.?

Just as bad there's a lot of inconsistency in how packages do various things and use the core tools.

So ... for our second release cycle I'd like to see simplification in the form of ripping out duplicate stuff (we don't really need two db api's, do we?) and hacking on various packages so there's a lot more consistent use of intrinsic concepts like permissions, inheritance, etc.

I took certain baby-steps in that direction while whacking on this thing, for instance providing Tcl API for the uploading of content to the content repository that deals with text vs. non-text, LOB vs. filesystem content storage but only modified a couple of packages to use it.  Those that do are a lot cleaner and straightforward than those that continue to "roll their own".  This is an example of duplication of effort outside the core that was fixable by extending the CR's Tcl API.

There's tons of examples of this sort of thing.

Each module seem to use the core API differently.  Its nice to have flexibility but they do have their own strokes.  Some even roll their own stuff.  There are also some packages that are acs_objects happy.  I think some of the tables that these packages should not use the acs_objects table anymore.  The acs_objects is already big so maybe we find some tables that does not need to have an acs_objects entry.  On one of our sites in just 2 months use we have already around 20,000 rows on it or maybe bigger.... hehehe.  Still some modules use their own templates.  Some modules use this API, some use another API, still some create their own API that is essentially what is already done on the core API.  Still some use their own permission that is essentially the same as the generic read, write, admin.

This is a general impression that I got after developing for a couple of months with OpenACS 4 with different sites and modules.  So I am gathering some opinion and voicing out my opinion that we should do trimming first before adding major stuff.  The existing one is feature rich as it is although there are a lot of stuff to add.  But in my opinion in the long run trimming it down or reviewing it will be more beneficial than adding and adding more features to it.
My opinion is to trim and review things before adding stuff.  Boring but I think after this boring phase things will be exciting again.  I vote for the boring phase for the next release.  I will help even though its boring.  I am kinda used to the CR now.

For the second release cycle I'd put my hat in the right for the Clean Up Crew.

We should also come up with a complete style guide that must be followed if you
want to submit a module to the repository. For modules already in the repository
we can go through and clean them up to abide by the style guide.

Hopefully we can clean this thing up and make it easier for people to develop
modules and sites.

1. A style guide for module/package makers.

2. A core clean up crew to clean the core.  (I will sign up for the core clean up crew, I will try to make myself available if it starts).  I think after the first release we should start building the core clean up crew.

Item #1 will me mainly documentation and probably some existing modules that follow the style and guidelines.  This can be broken down into 2 sub projects.  Documentation and examples, and maintaining a repository of good modules that follow the style.  An individual or group will see if a module qualifies to be in the central repository.  The a core OpenACS group will maintain the core but the modules will be done by its maintainers.  Will the new OpenACS site have somekind of a code repository?