On Wed, Jan 28, 1998 at 01:58:55AM -0600, Jason L Tibbitts III wrote:
> >>>>> "MTA" == Mordechai T Abzug <morty@sled.gsfc.nasa.gov> writes:
> MTA> The second problem is relatively trivial to solve, but the first is
> MTA> much more tricky. I was thinking hacking around with 1.94.4, but
> MTA> before i do: is some facility to handle this sort of issue going to
> MTA> appear in 2.0?
>
> Well, exactly how do you want to handle it?
Rats. I was under the impression a facility like this was going to be built
into 2.0.
[caveat: I haven't looked at the code for Mj2.0 yet]
This is how I'd handle it. Define a set of operations that you can do to
a subscriber list. I think they're basically:
Add this address to the list
Remove this address from the list
Is this address in the list?
How many addresses are in the list?
Give me the first address in the list
Give me the next address in the list
That gives you either one function prototyped as
sub do_list_action {
my $list_name = shift; # List to work
my $action = shift; # Action to perform ('add', 'remove'...)
my $address = shift; # Address (if the action needs it
...
}
or a bunch of functions, one per action listed above.
As J Random Hacker I could then write my own replacements for these
functions that looked up/stored information in a backend database, or DBM
file, or whatever.
Two further refinements spring to mind. The first is that what I've
outlined above is basically (in Perl) a tied array, a slightly complex
concept, but very powerful.
A second refinement (and probably the one I prefer) is to implement each
mailing list as an object with methods.
Code to deal with a list then looks something like:
my $list = new Majordomo::Lists "majordomo-workers";
$list->subscribe("foo@example.com");
$list->unsubscribe("bar@example.com");
...
the config file for the list would then feature a directive that gave the
name of the Perl package that implemented the list. For example
package = Majordomo::List::Standard
would mean that this list is stored using the standard Majordomo mechanism.
You would have a 'base' class for a list, that defines certain natural
things, and then happy hackers like me can go off and do our own thing.
For example, if I wanted to write a list class that got user data from an
Oracle database, I'd like to be able to start writing:
package Majordomo::List::Oracle;
# This package implements a Majordomo mailing list storing all the
# subscriber information in an Oracle SQL database.
# Our base class is Majordomo::List::_Base, from which we derive
# lots of useful behaviour
use Majordomo::List::_Base;
@ISA = qw(Majordomo::List::_Base);
# Now we need to use DBD/DBI to get access to the database
use DBI;
# Object constructor. Call our parent's constructor, and also connect
# to the DB.
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my listname = shift; # Listname is passed to the constructor
my $self = $class->SUPER::new($listname);
# Now connect to the DB
$self->{_DBH} = DBI->connect("dbi:Oracle" ... )
return bless($self, $class);
}
# Add a subscriber to the list
sub subscribe {
my $self = shift;
my $sql = "insert into subscribers ...";
...
}
and so on.
Once I've got that implemented, I'd go back to my mailing list config
file and say
# This list's subscriber details are stored in an Oracle database
package = Majordomo::List::Oracle
and that, as they say, is that.
Hmm. I appear to have got slightly carried away :-)
Jason, if you're interested in something like this, I'd like to get
involved. I may even be able to persuade my employer that it's a useful
use of my time (given that I run most of the mailing lists that emanate
from this domain).
Even if I can't, it is the sort of thing I could work on at weekends and
some evenings.
N
--
--+==[ Nik Clayton is Just Another Perl Hacker at Interactive Investor ]==+--
. . . and relax
Follow-Ups:
|
|
