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

[Bèr Kessels]

Allie thanks!

So far, you ar ethe only one in this thread who actually manages to go beyond 
the "drupal suxors cause it cannot do this", or "do we want good ML 
integration in a general way",

I have taken your points and will use them as our list of demands form what a 
ML 2 forum sulution should do. 

One of /my/ main demands was that i wanted to preserve all the ML side 
features and make them synch with the forumside features.

Ber

Op vrijdag 30 december 2005 23:52, schreef 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