[consulting] the Ultimate forum based Malinglist Manager
John Sechrest
sechrest at jas.peak.org
Sat Dec 31 18:51:40 UTC 2005
Discussion phase: brain storming [Brainstorm, sort/organize, document,...]
Recognizing that we all have different problems that we
are trying to solve and that the many different existing and
future solutions might meet some needs better than others.
Since we can not get cleanly into the what problem are we trying to
solve discussion, we can spend time on the key decision points
in the tools space:
Key Questions for the brain storming. These are multiple choice
questions. I am trying to bound the discussion.
1) Should the tool be self contained, use existing libraries
or use existing MLM systems?
A) Write it all in PHP, so it is universally installable
and universally usable by drupal users. Simplify the
install. Simplify that feature set to meet the current
drupal model.
B) use a Library like Perl::BulkMailer to do all the hard work
on sending mail, but leave the user interface to drupal.
C) Use (pick your favorite) an existing MLM, as a way to
leverage existing MLN understanding.
2) Should Mail <-> Drupal gateway just do mailing list stuff
or should it be a general interface to drupal?
A) Mail -> Drupal so that I can get mail archived and linked,
but don't worry about anything but forums
B) Mail <-> Drupal so that forums as symetrical and cleanly
accessibly by both mail and drupal and work the same
both ways.
C) Any mail message is the same as any node. If mail comes in,
it should be a node including events, blog entried, forums
flexinodes any type of node
D) A mail message can represent several nodes, and commands to
adjust drupal. A mail message is a conversation, which
with appropriate tags can cause transformations of
drupal nodes.
E) it should be possible to experience a drupal site
completely by email. That you can see any node,
add any node, delete any node all by email.
F) Drupal and email are just different expressions of conversations,
the goal is for either tool to be used independently to have
a conversation. And when that conversation is done, that
it is intelligable. To achive this, drupal has to change
how it models nodes and events.
3) Mail list members and drupal members can have several
relationships:
A) Mail list members and drupal members are exclusive
either you are on the mailing list, you are on the
drupal membership, but not both.
B) Maillist members and drupal members are independent.
you can be on one, or the other or both
C) Maillist members and drupal members are the same.
If you are on one, you are on the other. You may
not be getting mail, but with a configuration switch
you can turn on and off mail sending.
4) Target size. How many members and how many mail messages
should be possible?
A) Drupal is aimed at small groups talking to each other.
and so while there might be many mailing lists, each
discussion is a small group discussion, hosting order
thousands of messages and order hundreds of people
But with hundreds of lists.
B) Drupal is broadly used, so it should be possible
to set up a mailling which supports hundreds of thousands
of members with hundreds of messages a day.
5) How many mailing lists are there?
A) There is a one to one relationship between each forum
and a list.
B) There is a one to one relationship between each node
and a list
C) There is a one to one relationship between the group
(role, organic group) and a list
D) There are as many mailing lists as are created. They get
created as an object of thier own.
For me, the answers are:
1 B - The existing mlm's confuse the process and break the drupal
metaphore. use libraries to engage the power of mlm experience,
but leave the web work to drupal.
2 E - I would like to fully experience drupal by email, with no
use of web. I recognize that this has both security and
coding issues. And so as an interim, I would be happy
if D were true, that I could have an email conversation
that was both archived and changed other nodes at the same
time.
3 C - Maillist members and drupal members are the same. There is
no difference between the membership. What people see is
a function of the configuration they personally set.
4 A ) I see each conversation having small numbers
of messages going out. otherwise it fails to be a conversation.
5 C ) There is a one to one relationship between roles, groups and
mailing lists.
Does this process help anyone get closer to the problem that they
are trying to solve?
% >
% > 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
%
% _______________________________________________
% consulting mailing list
% consulting at drupal.org
% http://lists.drupal.org/mailman/listinfo/consulting
%
-----
John Sechrest . Helping people use
. computers and the Internet
. more effectively
.
. Internet: sechrest at peak.org
.
. http://www.peak.org/~sechrest
More information about the consulting
mailing list