[development] Re: [consulting] the Ultimate forum based Malinglist Manager

[Allie Micka]

On Dec 30, 2005, at 3:17 PM, Gerhard Killesreiter wrote:
>> So that's easy! you save yourself a ton of headaches when you  
>> stop  trying to shoehorn Drupal into being a mailing list manager,  
>> using a  real MLM to do your heavy lifting.
>
> Why would you want to use a MLM at all? All it does (cum grano  
> salis) is to tell you which addresses belong to which list.

I am hosting many mailing lists that are well-established.  When the  
opportunity for some of these lists to move to forum-based solutions  
comes up, this solution is rejected explicitly or implicitly (through  
non-use).  Meanwhile, people use, know and have come to expect mail- 
based functionality (unsubscribe, digest, etc.)

Why would you choose to take this functionality away from users when  
it already exists - and does a good job?

The other point that has been cut out of my original message is  
performance and scalability.  This is not optional, nor is it cost  
effective to attempt to get the same performance out of a new toolset  
as you can get from established standards.

The problem is not that we don't have good, stable, feature-rich  
MLM's.  The problem is not that we don't have good web-based user/ 
content management (duh!).  The problem is that there isn't a  
sufficient amount of glue between them.

>> Subscribers can use the list the  way they always have and you  
>> don't have to do much coding at all.
>
>
> I think that the traditional way of using listservs (trough email  
> commands) will die out sooner or later.

This is certainly a matter of opinion, though I would argue that the  
usage patterns of my customer base indicates otherwise.

> Since we already use a web based service (Drupal) why bother with  
> another interface? Recreating the few options that listservs offer  
> isn't that hard if you use an establshed CMF.

Again, good MLM's provide more than a few options and are in active  
development.  Do we want to be in the business of re-implementing a  
good MLM, or do we want to be in the business of building a good CMF?

>>   Necessary too, since Drupal  will post to the list on behalf of  
>> a user, and it would be nice if  that user is subscribed.  ezmlm- 
>> idx uses a MySQL/PostgreSQL database  for managing subscriptions,  
>> moderator addresses, allowed and denied  users.  It is absolutely  
>> trivial to access these tables for the  purposes of subscriber  
>> management.
>>
>
> Yes, that sort of thing is nice, I did the same for Sympa.  
> Unfortunately neither Sympa nor ezmlm-idx are the morst favoured  
> MLMs. People usually want mailman which interface to its user data  
> is hideous. Of coure, Mailman 3 will do all we ever will need. The  
> question is when. :p

Here's the question though:

   - How many hosts provide ezmlm lists?  (more than a few)
   - If someone uses the CivicActions model and writes Mailman hooks,  
how many hosts will support the solution? (lots)
   - Now, how many hosts will support custom queuing/de-queuing  
scripts from a web-based CMS?  Why should the support concerns  
surrounding this become Drupal's problem?

More importantly, I want to provide a many-to-many relationship  
between lists and Drupal installations:
   - You should be able to subscribe to both chapter-only lists and  
to a national organization's list on each chapter site.
   - You should be able to have subscribers that haven't been forced  
through the user account creation process.
   - If a list is fast, secure and stable on its own, you shouldn't  
have to force its operation through a CMF.
   - Vendor independence is important - you should be able to change  
out Drupal if you want, without having it affect every piece of your  
online infrastructure.

> This short list already has too much duplication for my taste.
>
> I'd like to discuss possible shortfalls on my idea to replace the  
> MLM with a script that directly accesses Drupal's database to get  
> subscribers and mail content to feed it to the MTA (and also does  
> the reverse for incomign mail).

What happens to subscribers who are not users?  Some of my mailing  
lists have 40,000 recipients or more, yet only a handful even visit  
the site.  Do we really want 40,000 inactive users in the site's  
database?

If the only hard requirement is managing subscription status via  
Drupal, what is the benefit of reinventing the MLM instead of  
focusing on that requirement?

How is that not duplication of existing efforts (the efforts of  
Mailman, ezmlm, et all)?  Do you really want to be in the business of  
supporting users in their efforts to feed database output to MTA's?   
How is this an improvement over phplist?

As a hosting provider, we manage a cluster of mail hosts, which is  
completely separate from the web host.  This is very common.  It  
means that we don't support users putting arbitrary queuing/dequeuing  
scripts on the mail hosts, but we do provide list services.  I would  
be happy to install these one-off scripts if it meant I could get  
some competitive advantage over the Drupal community.  But is  
creating vendor lock-in this way good for the Drupal community?

The Drupal community will benefit from a focus on leveraging existing  
solutions, with already-established solutions providers and  
documented support/installation procedures.  You don't solve any  
implementation problems by rewriting an MLM, but you take away  
support options and hosting choices.


Allie Micka
pajunas interactive, inc.
http://www.pajunas.com

scalable web hosting and open source strategies