Forum OpenACS Q&A: Integration between Mailman and OpenACS? (mailing list and bboard unification)
A group likes the ACS but loves their existing Mailman. They don't
want bboard as they don't want to subscribe to two mailing lists to
listen to a conversation. And they want to be able to keep their
email in their favorite email client. And yet, it's such an odd
website they propose: neighbor to neighbor, classifieds, general
comments, polls, with only a pointer to their mailing list archives
and no way to post a new message online.
Have there been any efforts to unify bboard with a mailing list
manager? One that handles bounces, and ensures mail loops don't take
Sounds like a great idea to me! Hopefully someone has an answer!
Scott wrote: We have two types of people...ones that love bboards and ones that love email and never the twain shall meet...
We also have these two types of people! I'd also like to see the integration.
A few months back, I wanted a way for the email people to be able to post messages to the bboard. I never solved the various issues... stuffing the database with email replies and tracking which thread it belongs to.... Ideally the root_msg_id would be hidden from the email user....
Then there is
> > is the typical
> > quote the whole long
> > thread problem
So I stopped. But I'm still interested....
Without getting too deeply into philisophical contemplation ("just how many times should one rewrite something as fundamentally simple as a bboard module?") the pieces are all there to integrate e-mail with ACS3 bboards and later ACS4 bboards. The hack done for ACES uses Oracle routines to grab the e-mail messages but of course non-Oracle pieces exist for web mail, which is included in OpenACS 3.2!
I'd love it because I'm going to need it myself later this spring or early summer.
Pieces pieces everywhere ...
I'd love to see someone do an integration with OpenACS 3.2. The "mail to OpenACS which then alerts members who've asked for them" paradigm means there are no mail loops unless someone registers with the system 's e-mail address as their user name. It would be easy enough to refuse such registrations...
I don't want to make this more difficult than it is, but how would you have a mail to "OpenACS which then *emails* people who've asked for them" mechanism handle bounces?
Right now with bboard, the author gets the bounces (and the vacation messages)
It appears that a significant portion of Mailman and ezmlm (presumably others) implements the proper handling of bounces so that mail loops from bounces don't form, and so that after a certain period of time, bouncers are unsubscribed.
Do you think there is any benefit to unifying bboard and say, ezmlm, or is it just making things overly difficult? I'd prefer to keep things simple and just hack at bboard, but I am afraid of having an errant mail header bug on my part make me persona-no-grata across half the net.
By the way, in a private email, I was told that Ben has mentioned in general wanting to integrate mailing list activities into OpenACS 4. Do you know what the plan is?
I just discovered that EZMLM mailing list with the IDX extensions has the ability to use SQL databases to store the mail list.
I wonder if the tables that ezmlm-idx requires could be views of openacs tables such as users and perhaps groups. Then admin users or members of a group would automatically be subscribed to the group mail list....
I also subscribed to the Mailman developers list. Turns out there's a guy at greatbridge trying to integrate PostgreSQL with Mailman, but no telling when that will be done (it's for Mailman 3.0, if you understand...)
As a total aside, I will mention that I was using a Zope based Wiki that they use to collaborate on various Mailman projects, and it is a very nice tool. The ACS would do well to get a Wiki module: a quick and very powerful method of web collaboration.
Most importantly, it's not clear to me how we could or should map the two data models to each other. ezmlm requires that it be able to add and remove e-mail addresses in response to e-mail requests. Does this mean that we would effectively be giving ezmlm the authority to register new users in OpenACS? Should unsubscribing from a list also remove you from the ranks of OpenACS users?
And which table would ezmlm be modifying -- parties? users? people? Or would we have to create a view for ezmlm, along with one or more rules that would fire the appropriate user-defined functions for creating and removing users?
I really like the idea of plugging these two technologies together, but there's a slight disconnect between them. Any ideas would be welcome.
I think allowing users to add/remove themselves from a list over email might be redundant, though if ezmlm allows it, you could have the function just delete them from a group (3.x thinking...sorry, haven't played with 4.x enough), or better yet just toggle a switch about receiving email while being a member. Adding should probably go through the normal registration process.
And that all depends on which piece of the equation you want to lean on more heavily. Rewriting a list manager for OACS is a lot of work, though it probably guarantees good integration with OACS. Reusing an existing one like ezmlm could be nice, if it can do everything we want of it and if the things we don't want can be disabled.