aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/comment_by_mail.mdwn
blob: ed9db06214ec880025ac11c9380064395cf15cd1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
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 :-)  --[[David Bremner]]