You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <nm...@byteaction.de> on 2006/07/12 15:06:02 UTC
MINA integration
Hi guys,
i whould like to work on MINA integration for connection handling. I
just want to know what you guys think about a problem...
Currently MINA only support SSL with java 5. So SSL can only be used
with java 5. I think its not a big problem cause the SSL support is
still experimental. So if someone want use it he must upgrade, if not he
can use james with java 1.4 (MINA itself works with java 1.4).
Anyone see a problem with it and so with integrate MINA ?
bye
Norman
Re: MINA integration
Posted by Mike Heath <mh...@apache.org>.
On Sat, 2006-07-29 at 13:06 +0200, Stefano Bagnara wrote:
> Mike Heath wrote:
> > HausMail is ASLv2.0. It is not LGPL. Never has been.
>
> I think the misleading info is there:
> http://hausmail.safehaus.org/Licenses
This page has been fixed. Thanks for pointing the problem out to me.
<snip>
> I don't think that it will be good for MINA to have protocol handling
> subprojects, btw If the directory PMC decided this way then I agree with
> you and I think that your SMTP implementation should be contributed to MINA.
>
> We could not accept it now because of the java 5 dependency and maybe it
> is now much more different from our new smtp handler architecture. I
> remember we had a similar pattern 1 year ago, but then we both evolved
> in different ways.
>
> Either way if it will be part of MINA we could anyway borrow code/class
> from you and I hope that you can help us if we'll need suggestions on
> MINA/SMTP as you have that knowledge.
>
> What are the timings for this MINA move?
I agree that with MINA part of the Directory project, adding protocol
handlers doesn't make a lot of sense. MINA is working towards becoming
a TLP. When MINA becomes a TLP, it makes a lot of sense for the project
to host implementations of as many protocols as they can. Having
pre-built stable implementations of protocols adds a great deal of value
to the MINA project.
As far as timing goes, I'm not sure. I've got some personal issues I
need to work out so that I can devote the appropriate amount of time to
this. There still needs to be some coordination with the MINA project
as well.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
Mike Heath wrote:
> HausMail is ASLv2.0. It is not LGPL. Never has been.
I think the misleading info is there:
http://hausmail.safehaus.org/Licenses
I remembered a bad link somewhere ;-) .. Btw I checked the src headers
and they report ASL2, so the bad reference is only on the website.
I saw you also have an SPF handler. You should consider replacing your
spfjava with our jSPF. We should be much more rfc compliant.
> The code that's in HausMail is essentially a MINA based SMTP server-side
> protocol handler. There is a lot of Java 5 code in there (enums and
> generics) that may have to be refactored. There is also some
> experimental code in HausMail that needs to be tested/cleaned up.
>
> In all honesty, I'm more inclined to contribute the SMTP server code in
> HausMail to the MINA project. One of the motivating factors in me
> writing the HausMail code was because I needed something that could
> receive SMTP message but I didn't need a full mail server. I also
> wanted something that was much more embeddable than what JAMES is today.
> The other motivation for adding it to MINA is that there has been talk
> on the MINA list to adding some protocol implementations to the MINA
> project.
>
> The HausMail code seems welcome at the MINA project. I need to dedicate
> the time to get it moved over there and coordinate with Peter Royal and
> Trustin Lee. Does such a move make sense for the JAMES project? I
> think it does but that may only be my opinion. Either way, I'm more
> than happy to help get the code in HausMail into JAMES. I just think it
> makes more since to put the code in MINA and have JAMES use that code.
>
> WDYT?
I don't think that it will be good for MINA to have protocol handling
subprojects, btw If the directory PMC decided this way then I agree with
you and I think that your SMTP implementation should be contributed to MINA.
We could not accept it now because of the java 5 dependency and maybe it
is now much more different from our new smtp handler architecture. I
remember we had a similar pattern 1 year ago, but then we both evolved
in different ways.
Either way if it will be part of MINA we could anyway borrow code/class
from you and I hope that you can help us if we'll need suggestions on
MINA/SMTP as you have that knowledge.
What are the timings for this MINA move?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Mike Heath <mh...@apache.org>.
Sorry to come so late to the discussion. I've been trying to set aside
more time to get back into the open-source projects I'm apart of but
other things keep coming up that require my time.
HausMail is ASLv2.0. It is not LGPL. Never has been. I wrote a
distributed locking manager for JAMES a while ago that was LGPL. The
LGPL DLM is out on Source Forge somewhere but it has a number of issues
and I think there's a better way to solve the clustering problem in
JAMES but that's a discussion for a different thread.
The code that's in HausMail is essentially a MINA based SMTP server-side
protocol handler. There is a lot of Java 5 code in there (enums and
generics) that may have to be refactored. There is also some
experimental code in HausMail that needs to be tested/cleaned up.
In all honesty, I'm more inclined to contribute the SMTP server code in
HausMail to the MINA project. One of the motivating factors in me
writing the HausMail code was because I needed something that could
receive SMTP message but I didn't need a full mail server. I also
wanted something that was much more embeddable than what JAMES is today.
The other motivation for adding it to MINA is that there has been talk
on the MINA list to adding some protocol implementations to the MINA
project.
The HausMail code seems welcome at the MINA project. I need to dedicate
the time to get it moved over there and coordinate with Peter Royal and
Trustin Lee. Does such a move make sense for the JAMES project? I
think it does but that may only be my opinion. Either way, I'm more
than happy to help get the code in HausMail into JAMES. I just think it
makes more since to put the code in MINA and have JAMES use that code.
WDYT?
-Mike
On Wed, 2006-07-12 at 15:06 +0200, Norman Maurer wrote:
> Hi guys,
>
> i whould like to work on MINA integration for connection handling. I
> just want to know what you guys think about a problem...
>
> Currently MINA only support SSL with java 5. So SSL can only be used
> with java 5. I think its not a big problem cause the SSL support is
> still experimental. So if someone want use it he must upgrade, if not he
> can use james with java 1.4 (MINA itself works with java 1.4).
> Anyone see a problem with it and so with integrate MINA ?
>
> bye
> Norman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: MINA integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Only a fool can think we will have a 3.0 final out by the end of the
> year if you want at least to add IMAP and something more to it.
Who said that it would be?
> Imho it would be a good step if people would help on releasing 2.3.0
> final by september. This would be a great goal.
As soon as the bugs are out, v2.3 could be ready for release, although we
might wait for docs. And the next version after that could be v3, with the
changes to fast-mail that Norman is working on, the database changes,
perhaps changes to the Mailet API to allow better configuration, jSPF
support, ...
The reasons for calling it v3 would include changes to the database
structure and the config.xml.
> > We should maintain both. MINA is essential for scaling to large numbers
of
> > connections, and for STARTTLS, but not for the majority of JAMES users.
> Mantaining both will probably be an additional cost that will not bring
> anything in the long time.
I disagree entirely, and here is why:
The bulk of the code should be in the handlers, and the handlers should be
I/O independent. They should be entirely shared between the current and
MINA I/O frontends.
The handlers deal with data. Most of them are trivial. The "tricky" part
is dealing with the DATA command, but I think that it is pretty simple,
there, too. We are in the DATA state, which means a handler for processing
the accumulation of the message. We introduce a new handler type, instead
of doing it the way we do now, where the DATA handler blocks on I/O. The
same will be true later for sending things. A handler event that is called
to get the next line of data to send. So two new handler events: one for
incoming message data and one for outgoing message data.
Once we decide on the event handling, the first thing to do would be to use
the new events in the existing blocking I/O system. So when we start
working on SMTP, POP3 or NNTP, we should put the new handler type(s) into
place, and change the socket-based system to call the new handlers rather
than have DATA (for example) handle the socket itself. So we entirely hide
the I/O from the handlers, and test it with the existing system. Once that
works, adding the MINA front end should be the easy part, and almost ALL
code would be shared.
>>> Imho most of the code should be shared between MINA and non MINA
services.
>> +1
>> That was always the intent. The protocol handler should not care how it
>> gets the next package of data, just that it does. And, happily,
>> telnet-class protocols are line-oriented, making things easy.
> This is valid for MINA low-level APIs but not for MINA high-level APIs.
> MINA high-level APIs introduce the concept of message objects and codecs
> and we don't have this concept in James now.
And that's just fine. Just because we have a hammer, doesn't make
everything a nail. We don't want to use MINA for everything it could do.
We want a nice stable framework for I/O, including codecs for dot stuffing
(for example), but not content handling. So almost 100% of the code would
be shared between the current socket-based frontend and the MINA frontend.
Once we have decoded packets we call handlers to process them, and all of
those are I/O independent.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> Imho James 3.0 won't be out before mid 2007 (optimistic)
>
> That's not anyone else's goal, so I hope that it isn't yours. I'd like to
> see JAMES v3 by year end. But it all depends upon what one calls JAMES v3.
It's not a matter of goals, but what I guess.
Only a fool can think we will have a 3.0 final out by the end of the
year if you want at least to add IMAP and something more to it.
Btw, I don't really want to discuss about this. Maybe I will be wrong
and that you will be payed to work fulltime from now to december on
James 3.0, or any other miracle :-)
If you agree that we can start including MINA alternatives for our
protocols we'll decide in mid 2007 what to do with "non MINA services".
Maybe you are right and that we'll release James 4.0 in mid-2007 with
only MINA.
Imho it would be a good step if people would help on releasing 2.3.0
final by september. This would be a great goal.
>> Otherwise we could start implementing MINA based services while keeping
>> old services updated.
>
> We should maintain both. MINA is essential for scaling to large numbers of
> connections, and for STARTTLS, but not for the majority of JAMES users.
Mantaining both will probably be an additional cost that will not bring
anything in the long time. Btw we'll vote about this in mid-2007 ;-) We
can skip this war now...
>> Imho most of the code should be shared between MINA and non MINA services.
>
> +1
>
> That was always the intent. The protocol handler should not care how it
> gets the next package of data, just that it does. And, happily,
> telnet-class protocols are line-oriented, making things easy.
>
> --- Noel
This is valid for MINA low-level APIs but not for MINA high-level APIs.
MINA high-level APIs introduce the concept of message objects and codecs
and we don't have this concept in James now.
Imho it would be good to analyze even the high-level APIs and maybe
we'll not be able to share as much code with what we have now (our
handlers currently directly write strings to the socket outputstream).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: MINA integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I'm +1 to MINA usage for our listening services.
Same here.
> Imho James 3.0 won't be out before mid 2007 (optimistic)
That's not anyone else's goal, so I hope that it isn't yours. I'd like to
see JAMES v3 by year end. But it all depends upon what one calls JAMES v3.
> Otherwise we could start implementing MINA based services while keeping
> old services updated.
We should maintain both. MINA is essential for scaling to large numbers of
connections, and for STARTTLS, but not for the majority of JAMES users.
> Imho most of the code should be shared between MINA and non MINA services.
+1
That was always the intent. The protocol handler should not care how it
gets the next package of data, just that it does. And, happily,
telnet-class protocols are line-oriented, making things easy.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
I'm +1 to MINA usage for our listening services.
Imho James 3.0 won't be out before mid 2007 (optimistic). At that time
java 1.5 dependency for SSL support would be probably acceptable.
Otherwise we could start implementing MINA based services while keeping
old services updated.
Imho most of the code should be shared between MINA and non MINA services.
Stefano
Norman Maurer wrote:
> Currently MINA only support SSL with java 5. So SSL can only be used
> with java 5. I think its not a big problem cause the SSL support is
> still experimental. So if someone want use it he must upgrade, if not he
> can use james with java 1.4 (MINA itself works with java 1.4).
> Anyone see a problem with it and so with integrate MINA ?
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> I remember that our first smtphandler refactoring to support fastfail
>> (2005 SoC) has been partially based on hausmail architecture (command
>> pattern).
>
> No, it was generally what was described by Danny and myself a year or more
> earlier in the Wiki.
A bit of Time Machine:
http://www.mail-archive.com/server-dev@james.apache.org/msg04310.html
http://www.mail-archive.com/server-dev@james.apache.org/msg04305.html
http://www.mail-archive.com/server-dev@james.apache.org/msg04547.html
http://www.mail-archive.com/server-dev@james.apache.org/msg04596.html
and for completeness:
http://wiki.apache.org/james/FastFail
>> Furthermore hausmail has started as a refactoring of James
>> SMTPServer, so I think it should not be so hard to
>> merge/reuse things.
>
> No, we cannot use any of their code.
>
> --- Noel
He would have committed his code to James if the PMC accepted the java
1.5 requirement for SSL.
He started the hausmail project mainly because James was not ready to
accept his contribution.
He already told that he would be happy to rejoin James on this and
donate the code back to apache as ASL2, and I guess he said the truth.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: MINA integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I remember that our first smtphandler refactoring to support fastfail
> (2005 SoC) has been partially based on hausmail architecture (command
> pattern).
No, it was generally what was described by Danny and myself a year or more
earlier in the Wiki.
> Furthermore hausmail has started as a refactoring of James
> SMTPServer, so I think it should not be so hard to
> merge/reuse things.
No, we cannot use any of their code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
peter royal wrote:
> You may want to open communication with http://hausmail.safehaus.org/ as
> well, as they expressed interest in bringing their SMTP code to MINA,
> they may have some bits that can be used as well.
Mike Heath (hausmail creator) is already a James committer: he put the
project on safehaus because at that time James PMC didn't want to
include MINA.
I remember that our first smtphandler refactoring to support fastfail
(2005 SoC) has been partially based on hausmail architecture (command
pattern). Furthermore hausmail has started as a refactoring of James
SMTPServer, so I think it should not be so hard to merge/reuse things.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by peter royal <pr...@apache.org>.
On Jul 12, 2006, at 1:40 PM, Noel J. Bergman wrote:
>> You may want to open communication with http://hausmail.safehaus.org/
>
> HausMail is LGPL. Unacceptable license. Mike Heath is a former JAMES
> contributor, and is quite welcome to contribute directly to JAMES
> rather
> than try to spawn his own project.
fwiw, I think he's keen on re-licensing the code under the ASL..
http://mail-archives.apache.org/mod_mbox/directory-mina-dev/
200607.mbox/%3c1152118202.5056.5.camel@localhost%3e
-pete
--
proyal@apache.org - http://fotap.org/~osi
RE: MINA integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
> AFAIK the creator and copyright owner for the full HausMail is Mike
> Heath. It seems that Mike would be happy to donate the code to ASF
And we'd like to have him do so.
> And you know, he tried to spawn his own project because his own project
> was not welcome (mainly by you ;-) ) when he did it.
I know nothing of the kind. In fact, the e-mail you referenced in another
reply, says (from me to Mike):
> If you want to contribue to JAMES, which I believe is the mutual desire,
> doing development elsewhere just makes it a longer road to get into our
> codebase.
ref: http://www.mail-archive.com/server-dev@james.apache.org/msg04310.html
And, yes, you could re-write all of the handlers to be part of the MINA
framework, but that is not necessary, and would unnecessarily tie us tightly
to it. And with respect to Mike's observations about MINA and fast-fail, I
had already discussed it in detail with Trustin and Alex.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MINA integration
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Peter Royal wrote:
>
>> (The Java 5 requirement for SSL is because you can only do SSL w/NIO
>> in Java 5).
>
> The other thing we get from SSL w/NIO is STARTTLS. We could support the
> current socket-based SSL I/O for 1.4 users.
>
>> You may want to open communication with http://hausmail.safehaus.org/
>
> HausMail is LGPL. Unacceptable license. Mike Heath is a former JAMES
> contributor, and is quite welcome to contribute directly to JAMES rather
> than try to spawn his own project.
>
> --- Noel
AFAIK the creator and copyright owner for the full HausMail is Mike
Heath. It seems that Mike would be happy to donate the code to ASF so,
for a moment, try to think this is a possibility.
And you know, he tried to spawn his own project because his own project
was not welcome (mainly by you ;-) ) when he did it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: MINA integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter Royal wrote:
> (The Java 5 requirement for SSL is because you can only do SSL w/NIO
> in Java 5).
The other thing we get from SSL w/NIO is STARTTLS. We could support the
current socket-based SSL I/O for 1.4 users.
> You may want to open communication with http://hausmail.safehaus.org/
HausMail is LGPL. Unacceptable license. Mike Heath is a former JAMES
contributor, and is quite welcome to contribute directly to JAMES rather
than try to spawn his own project.
--- Noel
Re: MINA integration
Posted by peter royal <pr...@apache.org>.
On Jul 12, 2006, at 9:06 AM, Norman Maurer wrote:
> i whould like to work on MINA integration for connection handling. I
> just want to know what you guys think about a problem...
>
> Currently MINA only support SSL with java 5. So SSL can only be used
> with java 5. I think its not a big problem cause the SSL support is
> still experimental. So if someone want use it he must upgrade, if
> not he
> can use james with java 1.4 (MINA itself works with java 1.4).
> Anyone see a problem with it and so with integrate MINA ?
Good to hear.. let me know if you need any help :) .. Noel walked me
through the basic patterns in JAMES @ ApacheCon and it didn't look
like it would be too bad.
(The Java 5 requirement for SSL is because you can only do SSL w/NIO
in Java 5).
You may want to open communication with http://hausmail.safehaus.org/
as well, as they expressed interest in bringing their SMTP code to
MINA, they may have some bits that can be used as well.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: MINA integration
Posted by peter royal <pr...@apache.org>.
On Jul 12, 2006, at 9:36 AM, Norman Maurer wrote:
> I know .. and mike is also a james commiter if im not wrong so we
> have a
> good startin point. I think i whould start the work on POP3 or the
> RemoteManager cause its not so complex as the SMTP-Server..
Noel actually suggested starting with the NNTP server, since its not
as widely used.
> BTW, how long will it take to release the new version of MINA ? From
> mikes code i see that he use MINA 0.9x which is still unstable. IS it
> far away from stable ?
We highly recommend people to use the 0.9 series. The 'unstable'
moniker is relative to the API, not functionality. So for in-
development projects, having to do minor tweaks to match any API
changes that we make prior to 1.0 shouldn't be a large issue :)
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: MINA integration
Posted by Norman Maurer <nm...@byteaction.de>.
Am Mittwoch, den 12.07.2006, 10:08 -0400 schrieb peter royal:
> On Jul 12, 2006, at 9:36 AM, Norman Maurer wrote:
> > I know .. and mike is also a james commiter if im not wrong so we
> > have a
> > good startin point. I think i whould start the work on POP3 or the
> > RemoteManager cause its not so complex as the SMTP-Server..
>
> Noel actually suggested starting with the NNTP server, since its not
> as widely used.
>
I remember that but i think its better to start with the RemoteManager
cause its a simplest protocol we have ;-) And this will probaly give me
(us) a better understanding what we must change etc for MINA..
> > BTW, how long will it take to release the new version of MINA ? From
> > mikes code i see that he use MINA 0.9x which is still unstable. IS it
> > far away from stable ?
>
> We highly recommend people to use the 0.9 series. The 'unstable'
> moniker is relative to the API, not functionality. So for in-
> development projects, having to do minor tweaks to match any API
> changes that we make prior to 1.0 shouldn't be a large issue :)
>
> -pete
Ok, so i will start with 0.9.4.
bye
Norman
Re: MINA integration
Posted by Norman Maurer <nm...@byteaction.de>.
Am Mittwoch, den 12.07.2006, 09:24 -0400 schrieb peter royal:
> On Jul 12, 2006, at 9:06 AM, Norman Maurer wrote:
> > i whould like to work on MINA integration for connection handling. I
> > just want to know what you guys think about a problem...
> >
> > Currently MINA only support SSL with java 5. So SSL can only be used
> > with java 5. I think its not a big problem cause the SSL support is
> > still experimental. So if someone want use it he must upgrade, if
> > not he
> > can use james with java 1.4 (MINA itself works with java 1.4).
> > Anyone see a problem with it and so with integrate MINA ?
>
> Good to hear.. let me know if you need any help :) .. Noel walked me
> through the basic patterns in JAMES @ ApacheCon and it didn't look
> like it would be too bad.
> (The Java 5 requirement for SSL is because you can only do SSL w/NIO
> in Java 5).
>
> You may want to open communication with http://hausmail.safehaus.org/
> as well, as they expressed interest in bringing their SMTP code to
> MINA, they may have some bits that can be used as well.
> -pete
I know .. and mike is also a james commiter if im not wrong so we have a
good startin point. I think i whould start the work on POP3 or the
RemoteManager cause its not so complex as the SMTP-Server..
Thx for offer your help..
BTW, how long will it take to release the new version of MINA ? From
mikes code i see that he use MINA 0.9x which is still unstable. IS it
far away from stable ?
bye
Norman