>> 2)who decided that sendmail will be broken in 1.8
>Sendmail itself was not broken it missed a way to handle Mime.

but did the sendmail interface change?


>> 3)what 2 interface you can use? (isn't SendMailInterface an interface?)
>
>Don't understand this, the whole point is nobody wanted 2 interfaces 
>but did
>want all the code in a (optional) application this created a unsolvable 
>problem.

this does not need to be a problem

I think for the time beeing we can keep the SendMail interface in the core
and put the implementations in the application.

If the behaviour of the email builder changed , yes that is an unsolvable problem.



>> 4)if sendmailInterface is moved how will the core classes that use 
>> sendmail compile ?
>This is what the vote was about.

/me don't understand

classes will compile but not work?


>
> 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?
>

Fine see below.


>> 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
>>

>i allready explained most of these questions in other reply's, It now 
>seems that this was my idea to ask for the vote in the first place (it 
>was not), Ill keep all the
>old code and let the email work as a applications including its 
>examples now found and tested in cvs.

>This is the last time i ask for a vote that several of you pushed me to 
>call for to be nailed by several of the same people..

pff. 

The real problem is that somebody (not me, but I think an MMC meeting)
decided that the SendMail interfaces needed to be moved. This seemed as a good
idea at the time . but now clearly is not. I still don't know who idea it was


>Just to be clear i really don't mind that you VETO'ed it im more than 
>happy to let things stay as they are, the whole mess started
>with that several developers wanted 'all code related to email to be in 
>a application' the problem with the Interface and several
>classes (that nobody seem to use and know what they are about btw, 
>SimpleFormtoMailServlet???) are a result of that.


>I think its best to let the old way stay until 1.8 it only proves that 
>the core needs to be cleaned alot more, the domino effect is to large
>todo it now when moving something from core to application (in this 
>case emai).
If the sendmail interface did not change 



The result of these actions will be :

1) the mail interface will stay as it is


2) a new implementation of it will be in the email application that 
supports mime

>3) and the mail application will have a readme, explaining how to 
>switch (changing the sendmail.xml module's class naam)

That is the problem is it? as far a i understand it's not sendmail.xml that needs 
changes but the email builders right?

greetings

<<winmail.dat>>

Reply via email to