james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Thu, 17 May 2007 11:58:07 GMT
On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> >> Jukka Zitting wrote:
> >> > On 5/16/07, Stefano Bagnara <apache@bago.org> wrote:
> >> >> I think SMTP relaying is a common use case for JAMES Server and one
of
> >> >> the main goals so we should keep this in high consideration.
> >> >
> >> > ACK. I'll go for a single binary stream per message for now. We can
> >> > revisit that decision later if we want to look at better supporting
> >> > IMAP and webmail scenarios.
> >>
> >> ok!
> >
> > hold on a minute - i think we might be being just a little too hasty!
> >
> > noel, peter, danny and myself were talking through some advanced SEDA
> > based architectures that will cluster well. jukka's exploding mail
> > idea fits very well into this.
>
> IMHO the basic version MUST support a simple unparsed stream. Everything
> else should be done as an evolution.
>
> Btw, who is Peter?

royal

> > designing a complete mail (not just email) storage solution around
> > relaying IMHO doesn't really make much sense. however, it is a very
> > useful extreme border case.
>
> "border case"? I think many billions of mails are relayed every day on
> the internet ;-)
> Maybe this is not the best use case for JAMES Server, but this also
> happened because we don't correctly support large message
> streaming/relaying and big volume of messages.

border case in the sense of most extreme

one test for a good design is being able to handle border cases smoothly

> > there are various ways that various types of mail can enter the
> > system. the consensus was that it's best for the least possible amount
> > of processing to be done initially (perhaps even just writing a
> > temporary file and then writing the data to the permanent store using
> > another thread)
> >
> > the first stage storage should just store the raw mail and basic
> > meta-data about that mail. this should include some audit trail
> > information about the original of the mail. (note mail here, not
> > email.)
>
> +1, so we need at least to be able to process raw main as the first
> step, like I was telling to Jukka.

i think so

we looked at adding more SEDA stages to the initial input pipeline

here's an example main line:

1 protocol handling and temporary mail aggregation
2 permanent storage of raw data plus some protocol (not mail) meta-data
3 spool processing by main line spool mailets

probably good to do 2 using mailets this would allow unclustered
relays which do not wish to store their mail permanently to operate in
processing phase 2

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message