On 03/05/2011 09:07 AM, Ludovic Dubost wrote:
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.
Ludovic
Le 02/03/11 14:02, Kevin P. Foote a écrit :
> The Apache James Project[1] could fit such a request. I've seen it
> integrated into a few large scale frameworks before.
>
> [1]
http://james.apache.org/
>
> ------
> thanks
> kevin.foote
>
> On Wed, 2 Mar 2011, Paul Libbrecht wrote:
>
> -> I would be very interested to such a feature but I note that it is
> not a simple thing.
> ->
> -> The biggest importance of receiving mails is to respond to some
> notifications of actions that were originally created on the XWiki, to
> my feelings. This requires, for example, that a table is properly made
> to associate the responded mail and the action the notification is about.
> ->
> -> Another issue is to attribute the mail... sooo often are people
> using a different email!
> ->
> -> I note that such features as Drupal's MailHandler could be an
> example; they are very fragile.
> ->
> -> One of the worst examples is jira's mail receiving facilities: you
> can respond to jira notifications if this is enabled. This fails
> really easily and not well visibly when a slight change occurs!
> ->
> -> XWiki with its flexible programming might make it possible to make
> it better case by case. Let's hope.
> ->
> -> paul
> ->
> ->
> -> Le 2 mars 2011 à 06:43, Caleb James DeLisle a écrit :
> ->
> -> > "Every program attempts to expand until it can read mail. Those
> programs which cannot so expand are
> -> > replaced by ones which can." Jamie Zawinski
> -> >
> -> > XWiki doesn't have any means of receiving mail at the moment, the
> mail sending facility is an
> -> > extension which is bundled by default and I see no reason why an
> extension for receiving mail could
> -> > not be implemented, it just needs to be written.
> -> >
> -> > Caleb
> -> >
> -> > On 03/02/2011 12:32 AM, Gérard Turmel wrote:
> -> >> Hello
> -> >>
> -> >> I would like register somewhere in XWiki, the important mails of
> my mailbox.
> -> >> For instance to save mail maybe with some attachements in a
> specific Space.
> -> >> From my mail reader, just transfer the mail in xwiki mail adress
> and automatically
> -> >> the mail would be save in a specific area.
> -> >>
> -> >> The idea under this function is for instance to manage a project
> and to maintain
> -> >> a list of importants mail about the project (with attachements).
> -> >>
> -> >> Is there any solution to manage this functionality ?
> -> >>
> -> >> I am under XWiki Enterprise 3.0-milestone-2.34501
> -> >>
> -> >> Thanks a lot.
> -> >>
> -> >>
> -> >>
> -> >>
> -> >>
> -> >>
>
**************************************************************************************************************************
>
> -> >> Ce message et toutes les pieces jointes sont confidentiels et
> etablis à l'intention exclusive de ses destinataires.
> -> >> Toute utilisation ou diffusion non autorisee est interdite.
> -> >> Tout message electronique est susceptible d'alteration.
> -> >> SISTEER decline toute responsabilite au titre de ce message s'il
> a ete altere, deforme ou falsifie.
> -> >> Si vous n'etes pas le destinataire de ce message, merci de le
> detruire et d'informer l'expediteur.
> -> >>
>
**************************************************************************************************************************
>
> -> >> This message and any attachments are confidential and intended
> solely for the addressee(s).
> -> >> Any unauthorised use or dissemination is prohibited.
> -> >> E-mails are susceptible to alteration.
> -> >> SISTEER shall not be liable for the message if altered, changed
> or falsified.
> -> >> If you are not the intended addressee of this message, please
> cancel it immediately and inform the sender.
> -> >>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/