[pmwiki-users] Mail Post Manual Trigger

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Sat, Apr 30, 2005 at 10:19:18AM +0200, Joachim Durchholz wrote:
> 
>> 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.
> 
> Yes, that's one of the reasons MLMs are difficult, but it's not the 
> only one.

What others?

>> PmWiki wouldn't have that problem.  It doesn't accept contributions
>> by email.
> 
> Indeed, since PmWiki is PHP script it cannot accept *anything* via 
> email.

That's a non sequitur. PHP programs can easily accept mails, via the
IMAP module (which is standard since PHP 3).

This doesn't mean it *should* do that. But it's incorrect to say that it
cannot do it.

> I never intended to imply that we'd be processing incoming emails, at
> least not for this limited purpose.

OK. It seems like we can get away without it (which is good since
setting up a mailbox for PmWiki would complicate the setup).

I do expect that reading email will become a necessity sooner or later
though. But that's just my personal prediction, as accurate or
inaccurate as that of anybod else, and I'm fully prepared to be proven
wrong on this issue.

>>> 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.
> 
> False -- many MTAs place limits on the number of outgoing recipients
>  per message, and even if they don't, not separating the messages
> into smaller batches can cause other issues.

Hmm... TWiki has been doing mail notifications for quite some time, and
I never heard Peter Thoeny (or any TWiki administrator) comment on such
a problem. Either they send out each mail separately and never ran into
trouble with that, or typical batches never hit the MTA limits.

>>> 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.
> 
> Not necessarily -- one could have a single mailing list and some way
> to allowing subscribers to use the MLM to filter messages at the MLM
> level.

I'm still feeling uneasy as the prospect. I'm not sure that a typical
PmWiki administrator will be able to set up a mailing list that works
this way. I think even less could set up an entire MLM (I'd certainly 
have trouble with that). Then PmWiki would have to interact with 
multiple MLMs, each with its specific idiosynchrasies and limitations... 
if PmWiki did it all on its own, it would be easier on the administrator.

Besides, those PmWikis that run on webhosting accounts with little 
privileges will be very limited in their choice of options for their 
mailing lists, so this is probably not even an option for them.

>> (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.)
> 
> I think it'll realistically get implemented; I just don't like the
> approaches discussed thus far.  I have this feeling that there's a
> better, more powerful approach to this (probably based on WikiTrails)
> than simply tacking lots of email addresses onto individual pages in
> the wiki.

I can understand that feeling.

However, the basic problem is that there's an N:M relationship between 
pages and users who want to be notified about them. N:M relationships 
are never easy, so a certain degree of problems is unavoidable.

Whether you tack users to pages or pages to users, *some* operations 
will always require scanning either M or N pages, depending on what's 
tacked where. The intelligent choice would be to get a feeling for what 
operations are needed how often, and the relative sizes of M and N, then 
select whether tacking users to pages or pages to users is the better 
choice.

The second design choice point is whether one wants to represent users 
by their mail addresses, their Author signature, or an account ID.

Regards,
Jo