Said I:
> In all fairness, I have to say that mailman is an *excellent* mailing
> list manager.
Said David H. Adler:
> So why haven't you reimplemented it in perl? :)
Are you sitting comfortably?.... :-)
Because the tools aren't yet in place to allow me to do it
within a truly flexible and generic application framework.
If I'm working to a plan (and that's not to say I necessarily am) then
it goes something like this:
Presentation:
* Template Toolkit to allow presentation to be clearly separated from
application / data. This is pretty much complete.
Data:
* XML::Schema to allow XML data types to be specified in a manner which
can be "understood" and easily manipulated by various tools. With
a standard representation for our data structures it becomes much
easier to write tools like database abstraction layers, interface
generators (for view, edit, etc), and so on, that do away with 90%
of the tedious work in building such applications. This is the current
work in progress (the XML::Schema part). Hopefully, we might inspire
the various people working on DBA's like Alzabo, Tangram, etc., that
this is a Good Thing and convince them to work together, or at least
adapt their products to utilise a consistent schema representation so
that their products can work together.
Application logic:
* Regular Perl is just fine for writing the business/application logic
parts. Once you strip out the presentation and low level data
manipulation parts, things often become quite simple.
Framework:
* Camelot (or AO, Pope, etc.) as a generic application framework to
glue it all together. This should define high-level application
service in terms of the other components. For example, the "mailman"
service to display a subscriber list can be described in simple terms
like:
- extract the mailing list name from <this> part of the URL
(handled by a generic URL munging service)
- go fetch the subscription list for this mailing list
(handled by the data abstraction layer)
- display it using <these> templates.
(handled by the presentation engine)
Behold, in Crap ASCII Art[tm]:
+--------------+
| Application |
| (Service) |
+--------------+
|
+-------------------+-------------------+
| | |
+--------------+ +--------------+ +--------------+
| Data | | App. Logic | | Presentation |
| (Model) | | (Controller) | | (View) |
+--------------+ +--------------+ +--------------+
I'm of the opinion that re-writing mailman in Perl is something of a
futile excercise until we can do it *significantly* better than it has
already been done in Python. The only benefits I can see are that
Perl hackers would be able to hack on it without having to learn
Python, and we would be able to equalise this particular notch on the
Perl vs Python scoring stick.
I would like to see the Perl equivalent of mailman written as an
application component. You should be able to add it to your current
application framework by simply merging the mailman XML config into
your server XML config. All the other services it relies on (data
abstractions, MTA services, presentation tools, etc.) would be
specified in the same way.
Here's a *very* pseudo example trying to illustrate what I'm getting
at:
<appserver>
<my database abstractions>
...
...
<here's one called "foo">
<it used DBI, Tangram, and these are some params...>
</foo>
....
</dba>
<my mail transport agents>
<sendmail>...</sendmail>
<qmail>....</qmail>
...
</mta>
<my presentation engines>
<template toolkit rocks my world!/>
<here's a fancy config for lotsa graphics/>
<this one is for WAP/>
<and so on...>
</pres>
<my application called mailman config="mailman_config.xml">
<dba>foo</dba>
<mta>qmail</mta>
<present>tt-fancy</present>
</mailman>
</appserver>
The mailman_config.xml would define the individual nitty-gritty
services that it offers, making calls against the DBA, MTA, presenters
and so on.
<mailman>
<service id="subslist">
<acquire this from there via my dba>
<mangle this like that using doodah>
<present this like that via the presenter>
<ensure bob is your uncle>
</service>
...
</mailman>
By defining it this way, it should be much easier for other
applications / services to hook into the mailing list services
that mailman provides. So if you want to build an application which
merges an online FAQ system with a web bulletin board with a mailing list
then you can do so with the minimum of fuss.
I have to stop writing now. The nice men in the white coats tell me it's
time for my medication.
Hope that answers your rhetorical question :-)
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
