[pmwiki-users] RFC -- POP3 to PmWiki

[Patrick R. Michaud]

On Wed, Oct 04, 2006 at 08:28:44AM -0400, Crisses wrote:
>    I want to request comments on doing POP3->PmWiki.
>    Would everyone agree with subject->pagename?

There was a fair amount of discussion about a mail-to-wiki gateway
back in February 2004, one can see at least one of the threads
at http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/2371/focus=2430 .

One of the things that was discussed then (and that I still agree with)
is that it would be more useful to be able to post snippets of
email rather than the entire message.  In this case, one would
delimit text to be added to a page within the body of the mail
message, and presumably the delimiters would be used to
specify the name of the page where the content should be added.

So, for example, using (using "(:post:)" and "(:postend:)"
as sample delimiters until I come up with something better):

    From: alice at example.com
    Subject: What I think needs to be added

    Hello, I'm adding some text to a page below!  Enjoy!

    --Alice
   
    (:post Group.SomePage:) 
    This is text to be appended to Group.SomePage on the wiki.

    It can contain markup and anything else we might want.
    (:postend:)


So, whatever is processing the mail simply scans the text for
(:post:) and (:postend:) directives, grabs out what is in-between,
and posts it to the appropriate wiki page(s).

Of course, all of this could get a lot simpler to implement
when ?action=insert is available... :-)

>    What about allowing a separate "post by email" password?

This could work.  

>    I would recommend that the email address that posts go to NEVER be put on
>    a web page.  Otherwise you'll have a lot of spam in the wiki from
>    spammail.  

This is also an advantage of using the delimiters -- even if the
account gets spam it's unlikely that the spam would contain (:post:)
directives, so the content would be ignored.

>    The plan is that if I do this, I will be using a PHP pop3 module for
>    PmWiki.  At most, it can be called every time PmWiki is run.  

Personally I'd use a fetchmail or procmail script, but you're correct
that not everyone will have the ability to set that up, so if a PHP-only
solution is desired, than a POP3 library is probably the best way to go.

One thing that I know would bother me about a POP3 (pull) approach
would be the delay between the time I send the message and the
resulting content being posted to the page.  This is especially true
if the squelch is set fairly high, such as once per hour or so.
And if the squelch is set low, then that could generate quite a few
POP sessions (and I don't know how admins would feel about this).

So, somehow it'd be nice to see if a push approach could be
incorporated somehow... but at the moment I'm not sure what it
would be.

One interesting approach that could make things "push based"
might be for pmwiki.org (and/or others) to offer a generic 
mail-to-wiki gateway service for PmWiki sites.  Such a service 
would scan incoming mail for wiki posts, and then use standard 
HTTP calls to post the content to the appropriate wikis.

Here's how it might work:  suppose I'm running an "ABCWiki" site,
and I want to be able to post content via email.  I register
"ABCWiki" with the mail-to-wiki gateway service on pmwiki.org,
providing the the url of the site and any password that might be
desired to authenticate the gateway.  After registration, any
incoming mail to  wikigateway+ABCWiki at pmwiki.org would be
scanned for (:post:)...(:postend:) directives and translated into
POST requests for to my wiki.

Of course, I don't have to give out the wikigateway+ABCWiki at pmwiki.org
address to others -- I can just set up a forward address so that
mail to 'abcwiki at ...' is forwarded to wikigateway+ABCWiki at pmwiki.org,
which then handles the scanning and posting.

What's nice about this is that individual PmWiki site admins don't
have to deal with setting up an incoming mailbox, POP passwords,
making sure the mailboxes are cleaned, etc. -- they just register
the site somewhere and it acts just like an incoming post.

>    If someone has a better idea, or a way of forking the process to be
>    separate from the HTTP browser-called PmWiki process, I would appreciate
>    knowing, but I'm trying to see if it's feasible to do this in a way that
>    is system-agnostic.

Something that I have found that works very nicely is to have things happen
at the *end* of page processing by using PHP's 'register_shutdown_function'.

For example, when PmWiki detects that it needs to update the page index
(which can take quite a while), it does so *after* processing the request
and sending the results back to the browser.  The same thing is true
with the notify list, where there can be a lot of email messages that
need to be sent; PmWiki simply performs the processing "in the
background" after it has completed handling a browser's request.

Pm