30 May
2014
30 May
'14
6:10 p.m.
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
2 Jun
2 Jun
7:06 a.m.
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, vincent(a)massol.net <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:14 p.m.
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
<mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net <vincent(a)massol.net> wrote:
--
Thomas Mortagne
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:19 p.m.
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
(thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) 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, vincent(a)massol.net wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:46 p.m.
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#HConfigurationPa…
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, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
(thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) 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, vincent(a)massol.net 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
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
6:49 p.m.
On 06/02/2014 12:46 PM, vincent(a)massol.net 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
6:57 p.m.
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com))
wrote:
On 06/02/2014 12:46 PM, vincent(a)massol.net wrote:
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
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
7:09 p.m.
On 06/02/2014 12:57 PM, vincent(a)massol.net wrote:
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com))
wrote:
> On 06/02/2014 12:46 PM, vincent(a)massol.net 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
7:29 p.m.
On 2 Jun 2014 at 19:09:37, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com))
wrote:
On 06/02/2014 12:57 PM, vincent(a)massol.net wrote:
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
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com))
wrote:
> On 06/02/2014 12:46 PM, vincent(a)massol.net 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 “.[.]” 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3759
days inactive
3762
days old
8 comments
4 participants
participants (4)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
vincent＠massol.net