[pmwiki-users] RFC -- POP3 to PmWiki
crisses at kinhost.org
Fri Oct 6 03:48:36 CDT 2006
On Oct 5, 2006, at 2:31 PM, Patrick R. Michaud wrote:
> Of course, this isn't the only approach -- we can emulate any
> of the authentication/authorization capabilities in PmWiki,
> including authentication (i.e., "id:gateway") or simple
> shared passwords ("set a group/page edit password to 'secret_key'").
I think this is what I'm saying. We need the same API, regardless of
whether the post is a post-from-self or a post-from-remote, so that
individual sites with a variety of auth mechanisms can accept posts
consistently, and regardless of the email processing end, the emails
can be sent to other sites consistently. It's not the means to the
end that matters so much as the end (the API), so that developers can
create different mechanisms for send &/or receive.
So essentially we know the information being passed is:
a target page (with possible GET vars)
Somewhere in there needs to be the choice between insert contents vs
replace contents? Some sites may want to allow both. This could be
in the GET vars. But we also need to figure out a common API for the
How each email processing application handles receiving an email,
processing it, and sending the HTTP request isn't of concern if we
have only one way (or rather a set of guidelines) to send the email
that is consistent, and an HTTP request/receipt that is consistent.
Then it becomes a matter of picking and choosing between what works
best for each site. And a plug in can be made to handle "post only
if GPG signature matches" etc. And you can write your app in Perl :) :P
And the receiving end can possibly be used for other applications. A
web form on a plain ol' HTML website that adds something to a wiki
page on a remote site? Just have to be VERY careful about how things
are programmed for security, otherwise it could be very helpful in a
variety of environments.
More information about the pmwiki-users