5 Mar
2011
5 Mar
'11
10:06 p.m.
I agree that XWiki remains a mail client.
I agree that XWiki should define listeners and default behaviours to such listeners (such
as create a page, add a comment, or update a page).
I misread Sergiu's post in a funny manner:
fire events when new mails are deleted in the
mailbox
(as opposed to detected in the mailbox).
What's funny here is that using an IMAP (and not POP) client, one could indeed
maintain some xwiki pages (update, delete, rename). It'd be cute I find.
paul
Le 5 mars 2011 à 16:31, Sergiu Dumitriu a écrit :
It's a bit
comple to be a mail server as it creates administration
issues and requires a specific subdomain and routing.
An alternate solution is a mailbox and a scheduler job which pools the
mailbox. All the APIs are already there for that.
+1, XWiki itself should NOT be a mailserver. It should indeed be
configured to read an external mailbox, fire events when new mails are
detected in the mailbox, and then components can do what they want with
the new emails: convert them into wiki pages, notify users, send a
reply, etc.
> What's necessary is define a convention of where the content goes based
> on what is in the email (subject or specific marker or alias target
> address).
>
> I've aleady of few cases where we load emails. On our intranet we load
> job posting in our Recruitment application.
>
> However there is no generic loading mecanism for all of XWiki. I agree
> it could be interesting.
> I'm very interested in a feature that would allow an email discussion
> that is captured as comments in the wiki.