On 5/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
> On 5/16/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> Jukka Zitting wrote:
>> > On 5/16/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
