70 lines
3.7 KiB
Markdown
70 lines
3.7 KiB
Markdown
I would like to allow comments on ikiwiki pages without CGI.
|
|
I have in mind something like
|
|
|
|
* Use a pagetemplate hook
|
|
in a plugin (DONE)
|
|
* add a mailto: url to each page matching some pagespec
|
|
(currently every page gets a comment footer)
|
|
* this mailto url goes to an address identifying the page (something like
|
|
user-iki-FE653b@host.fqdn.tld). (DONE)
|
|
> I wonder if it would be more or less natural to put an encoded form
|
|
> of the page name in the email address? I'm thinking about something
|
|
> like `wikiname+index@host` or `wikiname+todo+comment_by_mail@host`.
|
|
> The basic transformation would be to call `titlepage($page)` (in the
|
|
> C locale), followed by replacing "/" with "+" (since "/" is not
|
|
> valid in mails). --[[Joey]]
|
|
>> I guess you are right, there is no point being more obscure
|
|
>> than necessary. I am leaning towards [something](http://www.cs.unb.ca/~bremner/blog/posts/encoding) not
|
|
>> calling titlepage but in the same spirit. --[[DavidBremner]]
|
|
|
|
* on the mail receiving end, these messages are either deleted, or ran through
|
|
a filter to be turned into blog posts.
|
|
|
|
- I'm thinking about how the filter should work. Within a
|
|
mail client, or as a batch tool to scan a mailbox? How to interact with version control, if at all?
|
|
|
|
* the same plugin can check for comments on a particular page next time the wiki
|
|
is generated, and add a link. (more or less done)
|
|
> If the filter just checks in the posts into revision control, the
|
|
> post-commit hook would handle updating the wiki to include those
|
|
> posts as they come in. --[[Joey]]
|
|
* work in progress can be
|
|
|
|
- [cloned](http://pivot.cs.unb.ca/git/ikiperl.git), or
|
|
- [browsed](http://pivot.cs.unb.ca/git/?p=ikipostal.git;a=summary)
|
|
|
|
|
|
Any comments? Write them here or send them to [[DavidBremner]]
|
|
|
|
> I don't want to derail this with too much blue-skying, but I was thinking
|
|
> earlier that it would be nice if ikiwiki could do something sensible with
|
|
> mailbox files, such as turning them into a (threaded?) blog display.
|
|
>
|
|
> One reason I was thinking about that was just that it would be nice to
|
|
> be able to use ikiwiki for mailing list archives. But another reason was
|
|
> that it would be nice to solve the problem described in
|
|
> [[discussion_page_as_blog]]. For that you really want a threaded system,
|
|
> and mailbox file formats already have threading.
|
|
>
|
|
> If that were done, it would tie into what you're working on in an
|
|
> interesting way, since the incoming mail would only need to be committed to
|
|
> the appropriate mailbox file, with ikiwiki then running to process it.
|
|
> --[[Joey]]
|
|
>> It is an interesting idea. I like that it uses an arbitrary MUA
|
|
>> as a "moderation" interface. One thing it made me think about is
|
|
>> how to encode reference (threading) information. One can of
|
|
>> course encode this into local-part, but I wonder if it would be
|
|
>> better to use header features of mailto (this could also be an
|
|
>> alternative to tagged mail addresses for page references).
|
|
>> Various client handling of mailto always seemed a bit fragile to
|
|
>> me but maybe I am just behind the times. Most headers are ignored, but
|
|
>> pseudo-headers in the body might work. For example:
|
|
>>[test](mailto:bremner@somewhere.ca?body=X-Iki-Page:%20test%0AX-Iki-thread:%20foobar). I hesitate to use the subject because every mail admin in the
|
|
>> world seems to want to add things to the front of it.
|
|
>> -- [[DavidBremner]]
|
|
>>> Although it is in python, just from reading the Debian ITP, it
|
|
>>> looks like
|
|
>>> [mnemosyne-blog](http://www.red-bean.com/~decklin/mnemosyne/)
|
|
>>> might be an interesting backend to use or at least steal ideas
|
|
>>> from :-) --[[DavidBremner]]
|