Forum OpenACS Development: Trim Down OpenACS 4.0

Collapse
Posted by Jun Yamog on
Hi,

Doing some coding with OpenACS 4.0 with some fixing and a couple of
production site made me think that...

"We should trim down OpenACS 4.0 before things goes out of hand or grows"

I do understand that there is the beta, I am not asking for it to be
done in beta but more of a general long term direction.  The same way
what happend to Aolserver.  Aolserver 2.x is so much more feature rich
than Aolserver 3.x.  In my opinion we have to trim or make things more
solid.  There are a lot of duplicate codes or different strokes in
OpenACS just like in the 3.x code base.  In 4.x I think it has gone
worse.  Documentation will be a key but I think maybe some real
decision making must be done by the gurus of OpenACS.  Atleast the
core OpenACS has to be more solid, the modules/packages may or may not
follow this.

So what are your opinion in the general long term of OpenACS?  Trim
down and clean things... or build and build on it?

Collapse
Posted by Lars Pind on
I'm definitely in favor of trimming, of light-weight.

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.?

Collapse
Posted by Ben Adida on
I'm a bit confused because OpenACS 4.x seems *significantly*
better structured than 3.x, with significantly less duplication of
work. Of course, there are still many things that can be improved,
but the system does work quite well for large-scale
development.

Jun, what specifically is bothering you?

Collapse
Posted by Don Baccus on
Well ...  there is a lot of duplication, actually, at least it seems like I run across a lot of it.

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.

Collapse
Posted by Ken Kennedy on
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.

Sounds great to me, Don. Makes things easier for us as module developers, makes things easier to explain to new system/module developers, and makes things simpler for "users" who need to go in and tweak things.

I'll definitely sign up to work on that...

Collapse
Posted by Jun Yamog on
What bothers me is what bothers Don too.

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.

Collapse
Posted by Don Baccus on
Well ... I think it needs to be a combination, frankly.  We need new packages for sure, and there are some general design issues I, at least, would like to visit.

But it's important that we not ignore the "boring stuff", as you put it.  We definitely need a "clean-up crew" to tackle some of this stuff.  I'm personally more than willing to put time into doing this, and I'm sure others are as well.

Collapse
Posted by Mat Kovach on
Actually I don't find the "clean up" that boring.  Of course, I find FORTRAN exciting also! Sometimes I find the best way to really learn something to is to clean an working system and make sure it continues to work.

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

Collapse
Posted by Ben Adida on
Jun, now you're talking about more than trimming down, you're
talking about defining a more standard way for packages to do
certain things. That is very much necessary, I agree. And
certainly you should keep voicing your opinion, I was only looking
to get more details :)

I also agree with Don that we can't keep focusing on the core
without releasing new packages. The core will never be perfect,
but we'll continue to refine it as much as possible over time.

Collapse
Posted by Yonatan Feldman on
While working on dotLRN I have run into several modules/library files/data
models that could use cleaning up. This includes everything from style to code. I
think we should start cataloging which modules/files need help so we can keep
track of them (and any progress made). So, if you run across something that
needs cleaning up post to this thread.

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.

Collapse
Posted by Don Baccus on
<i>We should also come up with a complete style guide that must be followed if you want to submit a module to the repository
</i>
<p>
Heh - I just posted something similar in a related thread here, glad to see I'm not alone in thinking this.
<p>What's the best way to start cataloging core clean-up issues?  I want to make sure we don't what we learn as we work with the code.
Collapse
Posted by Jun Yamog on
The way I see it I think its 2 big tasks

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?

Collapse
Posted by Stephen . on
"What's the best way to start cataloging core clean-up issues?" How about adding some categories to this bboard.