[pmwiki-users] Mail Post Manual Trigger

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Fri, Apr 29, 2005 at 11:37:22PM +0200, Joachim Durchholz wrote:
> 
>> Any questions left? ;-)))
> 
> Sure.  "Who's going to write this?"

:-)

> More to the point, automated handling of subscriptions, unsubscriptions, 
> bounced emails, etc. are traditionally the functions of mailing list 
> managers (MLMs), and I can tell you that writing MLMs isn't a trivial 
> exercise.  It's easy to write a bad MLM, it's hard to write one that 
> works well, reliably, or scales well.

MLMs are difficult because the same medium is used for sending and 
receiving - this offers a potential for mail loops that can quickly eat 
up all available bandwidth (both in bounce messages and if two mailing 
lists accidentally end up subscribing to each other). To avoid problems, 
MLMs must be rock-solid from day one - and I think that's the reason why 
writing a MLM is such a scare project.

PmWiki wouldn't have that problem. It doesn't accept contributions by 
email. It will never bounce a message, it will simply ignore what it 
doesn't understand. Commands sent by users are pre-canned by PmWiki, so 
there's little margin for error, hence little need for error feedback, 
so we don't enter into bounce loops so quickly.

It is conceivable that PmWiki grows into a full MLM one day, by 
accepting contributions via email. However, this can be postponed until 
we're reasonably sure that bounce processing and scalability are up to par.

> To borrow from Neil's message, a page that ended up with a few hundred 
> subscribers could quickly run into server limits and/or other 
> scalability issues, requiring a fairly complex solution.

Well, yes, but I don't think that it's the PHP/PmWiki side of things 
that will run into server limits. If PmWiki fires off a single email 
with multiple recipients, the work is done in the mail transport system 
and not subject to any PHP limits.

Of course, scalability can be a problem. Sending out mails for every 
change can eat up available networking bandwidth if you're not careful. 
However, I think that's something that the administrator should decide.

> But perhaps this realization points a way out of the dilemma -- rather
> than try to duplicate MLM functionality, maybe we could come up with
> a way to use existing MLMs to manage notifications of watch lists?
> Just a thought...(haven't had much time for thinking on this issue of
> late, so I'm just writing off of the top of my head here).

That would be a separate mailing list per wiki page. I'm not sure that 
MLMs scale to hundreds or thousands of mailing lists. OTOH I'm not MLM 
expert, so I don't have a real idea of the actual limits.


In general, I don't think that there any serious problems. It has worked 
well enough for TWiki, which isn't even near PmWiki's stability 
standards otherwise.

It's a whole lot of work still. PmWiki would have to acquire the ability 
to read POP3 mailboxes. Installation would require setting up that 
mailbox and telling PmWiki where it lives. It's certainly nothing that 
should be in the PmWiki core. I don't know who's going to write all that 
stuff. (Not me - my PHP expertise is a bit too limited for doing it with 
any confidence. Besides, there's a paying project looming at the horizon 
for me, and while that's good for my wallet, it's bad for the free time 
I could invest in it. The whole point is that I'd like to see it as a 
PITS issue with a realistic chance of being implemented this decade or so.)

Regards,
Jo