Thanks Thomas, By the way, I've added a description of a possible API for this mail component to the design page - any comments welcome, it's not final of course - it's not even started to be implemented in fact :) I also added more details about what's being done / remaining to do, don't hesitate to have a look and comment.
@Paul : dev is progressing fastly, but no as fast as remaining work ... What's taking time is implementing some industrialization features, that is make the app "future proof" by providing means to "migrate" the archive automatically if data structures change. I don't want this app to be a nightmare for the wiki admin ... And these features of course must be implemented for the first release to have a sense. I agree that we should discuss this in "Your feedbacks on a possible MailArchive application", initially this thread was about the differences between the mail archive and the Gsoc project. BR, Jeremie 2012/5/9 Thomas Mortagne <[email protected]> > On Wed, May 9, 2012 at 1:49 PM, Jeremie BOUSQUET > <[email protected]> wrote: > > I'm answering myself: in fact the script service should propose 2 > methods, > > 1 to fetch a number of mails from a configured mail server, the other to > > parse a mail. > > A user could do something like this : > > #set($messages = $services.mails.fetch($server, 10)) > > #foreach($message in $messages) > > #set($mail = $services.mails.parse($message) > > $mail > > #end > > > > The part that would create a wiki page + object from the parsed mail, > seems > > more difficult to be generic. > > I don't know if some kind of default mapping configuration could be used > > (as for profiles creation from ldap), that would map mail headers to > object > > properties. > > It can come in a second time though. > > > > Another thing that I don't know, is what xwiki is already able to do > about > > mails, and if this kind of API should be added to an already existing > > component, instead of adding a new one. > > There is no mail related component that I know. There is a mail plugin > but I don't think it's good to add more stuff in it. At some point we > will move this plugin into a component oriented architecture and > probably put any generic stuff from your project in it too. > > > > > Jeremie. > > > > 2012/3/20 jerem <[email protected]> > > > >> @Vincent : Well, I use javamail APIs to parse, in fact I extract the > fields > >> (getHeader('headername')), do some computations (dates, body parts > >> aggregation ...) and store the result in a MailItem object of my own. > Then > >> I > >> create the new page (or update) and object from the MailItem > information. > >> > >> If I move that part to a Java component, and provide a script service to > >> call it (and to retrieve the MailItem fields) from Velocity, how would > I be > >> able to pass a mail as parameter from Velocity ? > >> For now the method is something like : > >> > >> MailItem parseMail(javax.mail.Message mail) > >> > >> But maybe it would be some kind of "internal" component, not supposed > to be > >> accessed from wiki pages directly ? (so no script service for this part) > >> > >> > >> > >> -- > >> View this message in context: > >> > http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p7389069.html > >> Sent from the XWiki- Dev mailing list archive at Nabble.com. > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
