[pmwiki-users] RFC -- POP3 to PmWiki

Crisses crisses at kinhost.org
Wed Oct 4 13:10:54 CDT 2006


On Oct 4, 2006, at 11:25 AM, Patrick R. Michaud wrote:

> 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.

I disagree.

Wiki spammers will catch on.  If they aren't reading the lists.

>>    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.

I think that given how many people would want this but be in hosting  
or Win32 environments, this is best.

> 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).

I was thinking more along the lines that some POP3 servers only allow  
you to poll 1/minute or less often.

BUT at the same time that I'd be squelching the calls to 1/min  
default (as an example) someone could override it and make it every 5  
or 15 minutes.  If someone wanted 1/day that's fine.  Having the  
option was the point.

> 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.

I considered it and didn't like anything.

> 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.
That sounds like the voice of a volunteer!

My approach has the benefit of being pretty darned easy to implement. ;)

A centralized wiki push server is beyond the scope I was  
considering.  In the months that it takes to get that going, I think  
I could have a POP3 solution very quickly. ;)  And that would leave  
me free for the shopping cart ideas.

> 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.

All well and good.  Sounds different than what I'm thinking,  
however.  I'm my own email admin, so setting up another email address  
isn't hard...there should be able to be a "delete messages > 1week  
old" option, etc.

>>    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.

Then that's where this needs to be. :)  Any documentation? Hints on  
how to use the hook?

Crisses




More information about the pmwiki-users mailing list