CALL FOR: Email changes: drop email classes and Interface from the core
Called by: Daniel Ockeloen Total tally on this call : +4
YEA (4) : Pierre van Rooden, Rob van Maris, Michiel Meeuwissen, Nico Klasens
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (10): Eduard Witteveen, Jaco de Groot, Marcel Maatkamp, David van Zeventer, Johannes Verelst, Daniel Ockeloen, Rob Vermeulen, Kees Jongenburger, Rico Jansen, Vincent van der Locht, Gerard van Enk, Mark Huijser
This call is ON HOLD, after a petition by Kees Jongenburger, requesting for more information on this call.
The caller of the vote is requested to provide information regarding the changes (what they entail and what the consequences are), before voting proceeds.
The following questions were asked:
1) What [in the core email builder] was broken?
2) What 2 interfaces can you use?
3) If sendmailInterface is moved how will the core classes that use sendmail compile ?
a) (returning null + log message) is not acceptable. we need to remove it or return something good
b) as far as i known the interface of SendMail was not changed why do we need changes to sendmail.xml?
4) what wil happen to current code in the core that will brake? org/mmbase/module/builders/Email.java org/mmbase/module/builders/Vwms.java org/mmbase/module/MMUsers.java (what even that is) org/mmbase/servlet/SimpleFormToMailServlet.java org/mmbase/module/LinkChecker.java
Note that questions above are edited according to insight and that additional questions may be asked.
If questions have been answered to satisfaction voting will resume.
Note that you may still vote (or cahnge your vote), and votes are still counted, but the call will not be closed until this issue is resolved.
Daniel Ockeloen wrote:
CALL BY: Daniel Ockeloen CALL FOR: Email move / merge
A new version to email has been included as a applications since 1.6, We updated this in 1.7 to include alot of mine features but did introduced
some unclear classes. As part of the ongoing effort we now included all things related to sending mail to the correct applications (org.mmbase.applications.email) but
this means we now have some old classes and interfaces that bind the core against some of the interfaces now part of the email applications making it hard to
see as a optional applications.
We like to remove/change these methods for 2 reasons
1) the old email was broken, We feel its better that people get a warning (when upgrading to 1.7) and how to change their code then getting weird errors when sending multiple
mails the old way
2) the old code depends on methods already depreciated in the core and will break for 1.8 for sure
3) you can now 'use' 2 interfaces and mix old code with new code getting all kinds of errors.
We feel its a lot better to create one clear way or a error, so we want to do the following
a) change a depr. call in MMBase.java : getSendMail() to return null and print a clear error in the log explaining how to solve it (you should use getModule anyway).
b) turn sendmail.xml module default to 'inactive' with comments in this file on the 2 new options you can use (it will include a commnent : look to the readme of the new email app).
Who will effect this and how : People using email need to make a small change to their webpages (but remember the old one is broken), People who mail from java and use the getSendMail() method (they need to change the interface and use getModule("sendmail").
Daniel Ockeloen Submarine.nl/MMBased
START OF CALL: 12/01/2004 10:00
END OF CALL: 15/01/2004 10:00
[_] +1 (YEA)
[_] +0 (ABSTAIN )
[_] -1 (NAY), because :
[_] VETO, because:
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
