Forum OpenACS Q&A: couple of features I am working on (2.33 version)

Since the website I am putting up will have articles, stories etc and
support mulitple usergroups within the larger community I am working
with some mods which can be a prototyping exercise for the new ACS/pg.
1.(adding user_groups to calendar items so you can restrict them)
status: I implemented this and seems to work well
2.(adding an article type) so far this is just a modified bboard item
so that the entry forms are a little more meaningful (ie you are not
asking a question but posting a article)status: modified some of the
forms to account for the type but needs some work
3.(shared addressbooks) this would allow a addressbook to be shared
among members of a particular user group

anyway.. when we are ready.. would like to have people review the
changes and see if they are something we want to add to ACS/pg and
even ACS itself

2: modularity (response to 1)
Posted by Ben Adida on
I think it's great that people are motivated to write new functionality. In fact, I think ACS/pg will motivate new functionality to be written, since the Postgres crowd is bigger, better, and growing faster than the Oracle crowd.

There is, however, a second important part to growing the ACS in a decent way: true modularity. There is no such thing right now in the ACS, and we cannot afford to start expanding ACS/pg until we have such a framework that makes adding/enabling/disabling modules easy.

I'll be working on this stuff soon, but suggestions and ideas are definitely needed! That doesn't mean you should stop coding new modules! It's just that before we integrate them into an official release, let's try to adapt everything to this upcoming framework.

Start a design discussion on how to achieve this, Ben.  In particular,  we should be thinking about ways to make things like integration with scoping and groups happen in default ways automatically, a way to register with the general comments module that creates the appropriate  table inits and delete triggers with no need to hand-edit general-comments.sql, and should generalize access security (aD seems to be moving in this direction, I've not checked 3.1+ so this may be a red-herring).

Let's build a list of services that the ACS framework should provide to modules.

Since Tcl is not an ideal language for this, we should then think about how to cleanly provide the framework.  I should probably look at Tcl8 sometime to see if there's help there.  Of course, it craps with AOLserver3 at the moment but that presumably will get fixed.

Since my current priority has been to get my community website up and functional, its requirements are driving the need for new features.  (Also why I haven't gotten much done on 3 ).  In doing this, some limitations of the current framework become apparent (which is to be expected as it was largely driven by and then additions for customers).  I am not proposing throwing my code in to confuse matters but it helps illuminate some framework requirements.

(1) A community is made of of the larger community and then subgroups with specific interests which they may or may not want to share with the larger community.  The framework should support group membership and group privacy/security at all levels.

.. the 2.x version supports group membership at certain levels but not consistently

(2) information should be structured to support collaboration of different levels. This allows informatio to be shared among various sub groups as desired.  For, example, the current addressbook is a throwback to standalone apps.  ACS should support the capability to share your information with others at an individual level as well as a group level. There is some recognition of this in the contact manager module, however the it needs to be integrated into the overall framework

The key feature of ACS is its capabilty to support collaboration and we should revisit the modules to make sure they support this at an individual, group and community level.

I agree with Don that we need to start looking at the requirements now.. as that we can develop a consistent strategy for implementing features which support this.

Which leads me to YET ANOTHER MODULE..  it would be useful to have a module to track requirements to modules etc.. (this is starting to getto be big league methodology).  I haven't looked at the new Software Development Module and maybe we can do it through the bug tracker

Generally, in my experience doing large software development projects

feature request  -> requirements definition -> functional specification -> implementation/test etc

We have some of the pieces to support this, but not all

Of course, there is the problem of all the copius spare timewe have to work on this....  I agree the current focus should be to port and QA the 3.1 version. This is mostly thinking for next phases

BTW.. I am available for bug fixes and QA so feel free to assign bugs to me

A few things:
- definitely registration of modules in the way Don describes. That's what I want. We need to hash out the entry points for modules in the ACS processes.
- Jamie, the SDM can do future feature requests and all. It stands to be improved still, but it's getting there. Try it out!

According to Michael Yoon, aD is moving towards the same general direction in "group-ready" most of the modules.  He also mentioned that there will be major rewrites to some old modules most notably the bboard in the next major release.  This is also the direction I'm moving towards and thus I just sat back and see how aD is doing from time to time.

Oh, btw, I hacked bboard to be group ready (as well as cleaned up some of the "kludges" in msg_id and related DM fields) and passed a guy at a copy.  I made more (local) changes and my version is no longer compatible with the ACS.  So I'd suggest to get it from ybos guy if one is interested.