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. _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
