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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
