[xwiki-devs] [GSoc] Advanced Email Integration
Hi everyone/Jerem, I've seen that we've added the following GSOC project: http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/AdvancedEmailIntegrat... This looks quite similar to what Jerem is working on. Jerem, maybe you could tell us a bit more about your project and how it's similar/different than this GSOC. Jerem, any timeframe for a first version of your project to be visible? Is this something you're developing for yourself or do you plan to give it to the community or even to the XWiki project? I'd like to clarify this to know how to best organize this project to not duplicate efforts too much and instead to combine synergies. Thanks -Vincent
Hi Vincent, (had to subscribe to devs list before posting ;) ) *** The differences : - The GSOC aims at syncing a mail/jabber channel in a page comments, while my project aims at reading and storing (no mail sending) in wiki pages and not in comments. In my application, each mail is stored in a wiki page, each topic is stored in another wiki page. So for a thread with 3 mails you get 4 pages created. - For now it's not possible to send Replies from my application (though I plan to add this) - In my application all mails stored in configured mail server connection / account / folder are read and archived in wiki (it's possible to delete them or to keep them with READ flag set, so they're read only once) - mails are not displayed through page comments, but in different modes : livetable, threaded (re-create the discussion thread) or "forum"-like - my app has/will have many side-features (ldap integration, multi-servers, parameterizable mailing-lists, mail types, timeline view, statistics view by mailing-list, ...) To me, I would more see the GSOC project as a good opportunity to add the "Reply" feature to my own app but ... ;-) *** Timeframe What takes me the more time is to convert my app to use a Java XWiki Component ... With issues about accessing the old-core, and the conversion from Groovy to Java language ... If I keep it as it is (using a Groovy Class in a wiki page), it could be done in maybe a month or so. A bit less if I hide some unfinished features for a first version. I know it's far from best, but the major part of the code is located in a Groovy class so it's more a matter of transforming it into Java component(s). But please realize that I can't guarantee this deadline ... It'll depend on my availability. *** Scope I developed it to use the feature for my job, and I want to "offer" it to XWiki community as it works nicely and would be a great addition IMO. If you want to add it to XWiki I'm ok also of course, but it should remain open-source. But I'd may have to obtain "permission" from my employer, even if not developped during daily-job-time ... All I write seems to be their possession "by default" ... What's cool is that this application has nothing to do with my job's business. If you have more questions please let me know ... I could also provide some pictures snapshots so you get a better idea of what to expect. BR, Jeremie Le 19 mars 2012 08:24, Vincent Massol <[email protected]> a écrit :
Hi everyone/Jerem,
I've seen that we've added the following GSOC project:
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/AdvancedEmailIntegrat...
This looks quite similar to what Jerem is working on. Jerem, maybe you could tell us a bit more about your project and how it's similar/different than this GSOC.
Jerem, any timeframe for a first version of your project to be visible? Is this something you're developing for yourself or do you plan to give it to the community or even to the XWiki project?
I'd like to clarify this to know how to best organize this project to not duplicate efforts too much and instead to combine synergies.
Thanks -Vincent
Hi again, I added a page to present my work-in-progress, in Drafts : http://dev.xwiki.org/xwiki/bin/view/Drafts/MailArchiveApp For now I added some screenshots about Admin part only ... I'll add screenshots along with my progress ;) BR, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Note: we generally use http://dev.xwiki.org/xwiki/bin/view/Design/ for in progress (or just for the specs before starting) projects. You can indicate state of the project, lead, etc. On Mon, Mar 19, 2012 at 7:03 PM, jerem <[email protected]> wrote:
Hi again,
I added a page to present my work-in-progress, in Drafts :
http://dev.xwiki.org/xwiki/bin/view/Drafts/MailArchiveApp
For now I added some screenshots about Admin part only ... I'll add screenshots along with my progress ;)
BR, Jeremie
-- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
@Thomas : I moved my page to the Design space and deleted the old one : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication -- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com.
This is indeed different than the GSOC project I proposed. My aim in this project proposal is to get more close to a Skype/Social Network interaction level on top of an XWiki document. The objective is to be able to run a discussion on an XWiki document while having a a stronger interaction than what you usually have in the Wiki. Currently if you publish a document and then launch a discussion you will: 1/ Send a mail to a list or a group of people (this can be done using SendByMail) 2/ Ask the people to come annotate or comment 3/ Thanks to AutoWatch people can get this in their watchlist. Unfortunately the watch list is only hourly to the max and there is no guarantee that participants will actually read it. The objective with the Advance email integration would be to allow a much more real time interaction either in an email or chat system by allowing every user to be notified about an annotation of a comment (with a nice UI actually showing that comment) and by allowing to reply it in much simpler ways: 1/ Just responding to the chat message (jabber or skype) 2/ Just responding to the email The message would then be automatically added as a new comment or as a response to an existing comment or annotations (if we have threaded annotations). This would lead to new notifications to the participants of this discussion. The real time chat integration would be particularly interesting here (imagine a live group chat in skype or jabber where you can discuss a specific document), but email is interesting too (this could be tested in the dev lists with xwiki.org). In a chat integration, you could also decide to push the notifications to a existing group chat (the team chat or the irc channel), or decide to create a new group for that specific discussion. This could be the same with email with either individual emails or a push to a mailing list. Ludovic 2012/3/19 Jeremie BOUSQUET <[email protected]>:
Hi Vincent,
(had to subscribe to devs list before posting ;) )
*** The differences : - The GSOC aims at syncing a mail/jabber channel in a page comments, while my project aims at reading and storing (no mail sending) in wiki pages and not in comments. In my application, each mail is stored in a wiki page, each topic is stored in another wiki page. So for a thread with 3 mails you get 4 pages created. - For now it's not possible to send Replies from my application (though I plan to add this) - In my application all mails stored in configured mail server connection / account / folder are read and archived in wiki (it's possible to delete them or to keep them with READ flag set, so they're read only once) - mails are not displayed through page comments, but in different modes : livetable, threaded (re-create the discussion thread) or "forum"-like - my app has/will have many side-features (ldap integration, multi-servers, parameterizable mailing-lists, mail types, timeline view, statistics view by mailing-list, ...)
To me, I would more see the GSOC project as a good opportunity to add the "Reply" feature to my own app but ... ;-)
*** Timeframe What takes me the more time is to convert my app to use a Java XWiki Component ... With issues about accessing the old-core, and the conversion from Groovy to Java language ... If I keep it as it is (using a Groovy Class in a wiki page), it could be done in maybe a month or so. A bit less if I hide some unfinished features for a first version. I know it's far from best, but the major part of the code is located in a Groovy class so it's more a matter of transforming it into Java component(s). But please realize that I can't guarantee this deadline ... It'll depend on my availability.
*** Scope I developed it to use the feature for my job, and I want to "offer" it to XWiki community as it works nicely and would be a great addition IMO. If you want to add it to XWiki I'm ok also of course, but it should remain open-source. But I'd may have to obtain "permission" from my employer, even if not developped during daily-job-time ... All I write seems to be their possession "by default" ... What's cool is that this application has nothing to do with my job's business.
If you have more questions please let me know ... I could also provide some pictures snapshots so you get a better idea of what to expect.
BR, Jeremie
Le 19 mars 2012 08:24, Vincent Massol <[email protected]> a écrit :
Hi everyone/Jerem,
I've seen that we've added the following GSOC project:
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/AdvancedEmailIntegrat...
This looks quite similar to what Jerem is working on. Jerem, maybe you could tell us a bit more about your project and how it's similar/different than this GSOC.
Jerem, any timeframe for a first version of your project to be visible? Is this something you're developing for yourself or do you plan to give it to the community or even to the XWiki project?
I'd like to clarify this to know how to best organize this project to not duplicate efforts too much and instead to combine synergies.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
@Ludovic : to me also it's a really different concept, more chat-oriented. With the MailArchive the complete email is kept (including images, attachments and so on), while with comments and annotations you restrict to plain text content. Do you think both could be interesting (or even linked in any way) ? I could imagine something like that : - you send a mail - it's loaded by the MailArchive that creates a wiki page for it - if you click on a "Reply" button, you can use WYSIWYG to send a reply to this mail (that will later be loaded by the MailArchive) - if you comment or annotate the page, it also triggers a reply (your gsoc project) Your project would still be available independently because it's not only about mails (but also jabber or skype or ...), it could just be linked to the MailArchive mail pages for fast-replies and interaction. I already do that for the livetable excel export : if the extension is installed, you can activate it in the MailArchive livetables through configuration parameter. If the advanced email extension is installed, you could also activate it through a configuration parameter in the MailArchive for "fast replies" ... -- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com.
... by the way, the part that - parses a mail - stores it in an object in a wiki page ... could be something common and available as a component API to other components. So it could even be shared if both projects come to life. -- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Mar 20, 2012, at 12:18 PM, jerem wrote:
... by the way, the part that - parses a mail
For this part I'm sure there are generic java libraries out there that can help us with this. Maybe javamail does this too by default? Otherwise we could check James or other…
- stores it in an object in a wiki page
... could be something common and available as a component API to other components. So it could even be shared if both projects come to life.
Good idea. Thanks -Vincent
@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-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com.
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. 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-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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-tp7384822p... 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
Le 9 mai 2012 à 15:40, Thomas Mortagne a écrit :
There is no mail related component that I know.
Thanks to the mail plugin, mail-1.4.jar and activation-1.1.jar are there. That's javamail so brings you POP and IMAP somehow, I think. paul PS: I'm interested to this thread... there are several demands for such a feature on i2geo.net PPS: shouldn't this thread not be called GSoC?
On Wed, May 9, 2012 at 4:42 PM, Paul Libbrecht <[email protected]> wrote:
Le 9 mai 2012 à 15:40, Thomas Mortagne a écrit :
There is no mail related component that I know.
Thanks to the mail plugin, mail-1.4.jar and activation-1.1.jar are there. That's javamail so brings you POP and IMAP somehow, I think.
I was talking about a place where to put new generic methods.
paul
PS: I'm interested to this thread... there are several demands for such a feature on i2geo.net PPS: shouldn't this thread not be called GSoC? _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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-tp7384822p...
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
Yes that's the part that is the most common. For the rest, I'm not sure storing the discussion in separate pages would be good for the "discussion" concept. I think it's two different needs. Now the images could be still interesting in the discussion mode, though it's complicated if they are stored in comments Ludovic 2012/3/20 jerem <[email protected]>:
... by the way, the part that - parses a mail - stores it in an object in a wiki page
... could be something common and available as a component API to other components. So it could even be shared if both projects come to life.
-- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
At Curriki, I think, there would be an interest to leverage comments being almost full email-thread-discussions. Including images, indeed. Though I agree they're difficult but surely interesting. A typical use case I'd see is for teachers to publish how a learning resource has been used (the picture is not part of the learning resource but part of how it has been used; e.g. it could be anonymized version of a learner's sheet). paul Le 20 mars 2012 à 12:32, Ludovic Dubost a écrit :
Yes that's the part that is the most common.
For the rest, I'm not sure storing the discussion in separate pages would be good for the "discussion" concept. I think it's two different needs.
Now the images could be still interesting in the discussion mode, though it's complicated if they are stored in comments
Ludovic
2012/3/20 jerem <[email protected]>:
... by the way, the part that - parses a mail - stores it in an object in a wiki page
... could be something common and available as a component API to other components. So it could even be shared if both projects come to life.
-- View this message in context: http://xwiki.475771.n2.nabble.com/GSoc-Advanced-Email-Integration-tp7384822p... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
jerem -
Jeremie BOUSQUET
-
Ludovic Dubost -
Paul Libbrecht -
Thomas Mortagne -
Vincent Massol