[xwiki-devs] [Proposal] New Mail Sender module + API
Hi devs, I’ve worked with Lyes to define a new mail sender API. We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule Our idea is to: - implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui. - deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib. Please let us know what you think about both the API and the plan. Thanks -Vincent
Looks good. Just one small remark, usually when a method is overridden the extra parameters are added at the end. I'm referring to createMessage with cc and bcc. Thanks, Marius On Fri, May 30, 2014 at 7:10 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’ve worked with Lyes to define a new mail sender API.
We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
Our idea is to:
- implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui.
- deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib.
Please let us know what you think about both the API and the plan.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Ok to start working a new module. I will wait for the actual code for detailed comments on the API ;) Note; you are talking about xwiki-commons-mail-read module but I don't see much about read in the API design. On Mon, Jun 2, 2014 at 7:06 AM, Marius Dumitru Florea <[email protected]> wrote:
Looks good. Just one small remark, usually when a method is overridden the extra parameters are added at the end. I'm referring to createMessage with cc and bcc.
Thanks, Marius
On Fri, May 30, 2014 at 7:10 PM, [email protected] <[email protected]> wrote:
Hi devs,
I’ve worked with Lyes to define a new mail sender API.
We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
Our idea is to:
- implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui.
- deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib.
Please let us know what you think about both the API and the plan.
Thanks -Vincent
_______________________________________________ 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
ok, Lyes and I are going to work on it on xwiki-contrib here: https://github.com/xwiki-contrib/xwiki-platform-mail The idea is that when it’s ready enough, we’ll propose to move it to xwiki platform with history. Thanks -Vincent On 2 Jun 2014 at 15:14:51, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:
Ok to start working a new module.
I will wait for the actual code for detailed comments on the API ;)
Note; you are talking about xwiki-commons-mail-read module but I don't see much about read in the API design.
On Mon, Jun 2, 2014 at 7:06 AM, Marius Dumitru Florea wrote:
Looks good. Just one small remark, usually when a method is overridden the extra parameters are added at the end. I'm referring to createMessage with cc and bcc.
Thanks, Marius
On Fri, May 30, 2014 at 7:10 PM, [email protected] wrote:
Hi devs,
I’ve worked with Lyes to define a new mail sender API.
We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
Our idea is to:
- implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui.
- deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib.
Please let us know what you think about both the API and the plan.
Thanks -Vincent
_______________________________________________ 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
Hi devs, We’ll also need some configuration properties for the new mail sender module. I’m proposing http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule#HConfigurationPar... Let me know what you think. Note: Maybe it’s time to think about a generic mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)... Thanks -Vincent On 2 Jun 2014 at 16:19:20, [email protected] ([email protected](mailto:[email protected])) wrote:
ok, Lyes and I are going to work on it on xwiki-contrib here: https://github.com/xwiki-contrib/xwiki-platform-mail
The idea is that when it’s ready enough, we’ll propose to move it to xwiki platform with history.
Thanks -Vincent
On 2 Jun 2014 at 15:14:51, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:
Ok to start working a new module.
I will wait for the actual code for detailed comments on the API ;)
Note; you are talking about xwiki-commons-mail-read module but I don't see much about read in the API design.
On Mon, Jun 2, 2014 at 7:06 AM, Marius Dumitru Florea wrote:
Looks good. Just one small remark, usually when a method is overridden the extra parameters are added at the end. I'm referring to createMessage with cc and bcc.
Thanks, Marius
On Fri, May 30, 2014 at 7:10 PM, [email protected] wrote:
Hi devs,
I’ve worked with Lyes to define a new mail sender API.
We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
Our idea is to:
- implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui.
- deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib.
Please let us know what you think about both the API and the plan.
Thanks -Vincent
_______________________________________________ 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
On 06/02/2014 12:46 PM, [email protected] wrote:
Note: Maybe it’s time to think about a generic mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)...
How about this for a rule: Stop adding properties to XWikiProperties! -- Sergiu Dumitriu http://purl.org/net/sergiu
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu ([email protected](mailto:[email protected])) wrote:
On 06/02/2014 12:46 PM, [email protected] wrote:
Note: Maybe it’s time to think about a generic mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)...
How about this for a rule:
Stop adding properties to XWikiProperties!
Well you need to explain your thoughts more :) The goal of xwiki.properties is to: - define config values even when there’s no wiki page - define config values for all wikis Also note that we have a global Configuration system. You just ask for a property value knowing it’s name and it’ll find it for you by looking in all places. Those places are configurable (it can be in a properties file, in LDAP, in a DB, in wiki pages, etc). The issue I was raising is that we’re naming properties with “<module>.<name>[.<subname>]” in xwiki.properties while this is not a current convention in xproperties (actually we don’t have any convention ATM for xproperty naming AFAIK, sometimes it’s with “_” as in “smtp_host”, sometimes it’s in camelcase as in “displayHiddenDocuments" , sometimes with “.” as in “xwiki.preferences.redirect”). Thanks -Vincent
Sergiu Dumitriu
On 06/02/2014 12:57 PM, [email protected] wrote:
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu ([email protected](mailto:[email protected])) wrote:
On 06/02/2014 12:46 PM, [email protected] wrote:
Note: Maybe it’s time to think about a generic mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)...
How about this for a rule:
Stop adding properties to XWikiProperties!
s/XWikiProperties/XWikiPreferences/
Well you need to explain your thoughts more :)
The goal of xwiki.properties is to: - define config values even when there’s no wiki page - define config values for all wikis
Also note that we have a global Configuration system. You just ask for a property value knowing it’s name and it’ll find it for you by looking in all places. Those places are configurable (it can be in a properties file, in LDAP, in a DB, in wiki pages, etc).
The issue I was raising is that we’re naming properties with “<module>.<name>[.<subname>]” in xwiki.properties while this is not a current convention in xproperties (actually we don’t have any convention ATM for xproperty naming AFAIK, sometimes it’s with “_” as in “smtp_host”, sometimes it’s in camelcase as in “displayHiddenDocuments" , sometimes with “.” as in “xwiki.preferences.redirect”).
Yes, xwiki.properties is good, no objection to that. XWikiPreferences, on the other hand, is not scalable. - It is close to the limit of what can be stored in xwikidoc.XWD_CLASSXML, so besides what we currently have in the default class, users can add only a few more properties. - Telling users (be they admins, so hopefully a bit more knowledgeable than normal users) to open the class editor on XWikiPreferences (which is not easily accessible, by the way) and add a specific type of property, then open the object editor to set a value for it, is not user friendly at all, and leaves a lot of room for errors. - Adding them to XWikiPreferences means that they automatically appear in the space preferences as well, although not all preferences are taken into account at the space level. Thus, users might be confused by settings that don't work... The direction taken by Configurable sections is scalable, but it is not fully usable at the moment, since reading these settings requires custom code. I would invest into making it easy to read custom settings instead of describing how "new" XWikiPreferences properties should be named. There is no more space left for new xproperties. -- Sergiu Dumitriu http://purl.org/net/sergiu
On 2 Jun 2014 at 19:09:37, Sergiu Dumitriu ([email protected](mailto:[email protected])) wrote:
On 06/02/2014 12:57 PM, [email protected] wrote:
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu ([email protected](mailto:[email protected])) wrote:
On 06/02/2014 12:46 PM, [email protected] wrote:
Note: Maybe it’s time to think about a generic mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)...
How about this for a rule:
Stop adding properties to XWikiProperties!
s/XWikiProperties/XWikiPreferences/
ok that changes your email completely :) We all agree about not increasing the XWikiPreferences size and instead breaking down all configs by module (each module coming with its own Config page(s)). However my comment wasn’t about XWikiPreferences at all. I said "mapping between naming rules from xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)”. I was using XWikiPreferences as an example only. Not sure what’s your point here WRT my question :) Thanks -Vincent
Well you need to explain your thoughts more :)
The goal of xwiki.properties is to: - define config values even when there’s no wiki page - define config values for all wikis
Also note that we have a global Configuration system. You just ask for a property value knowing it’s name and it’ll find it for you by looking in all places. Those places are configurable (it can be in a properties file, in LDAP, in a DB, in wiki pages, etc).
The issue I was raising is that we’re naming properties with “.[.]” in xwiki.properties while this is not a current convention in xproperties (actually we don’t have any convention ATM for xproperty naming AFAIK, sometimes it’s with “_” as in “smtp_host”, sometimes it’s in camelcase as in “displayHiddenDocuments" , sometimes with “.” as in “xwiki.preferences.redirect”).
Yes, xwiki.properties is good, no objection to that.
XWikiPreferences, on the other hand, is not scalable.
- It is close to the limit of what can be stored in xwikidoc.XWD_CLASSXML, so besides what we currently have in the default class, users can add only a few more properties. - Telling users (be they admins, so hopefully a bit more knowledgeable than normal users) to open the class editor on XWikiPreferences (which is not easily accessible, by the way) and add a specific type of property, then open the object editor to set a value for it, is not user friendly at all, and leaves a lot of room for errors. - Adding them to XWikiPreferences means that they automatically appear in the space preferences as well, although not all preferences are taken into account at the space level. Thus, users might be confused by settings that don't work...
The direction taken by Configurable sections is scalable, but it is not fully usable at the moment, since reading these settings requires custom code. I would invest into making it easy to read custom settings instead of describing how "new" XWikiPreferences properties should be named. There is no more space left for new xproperties.
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
vincent＠massol.net