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: Let's Create An Alternative To MIMEMessage
Date Thu, 12 Jul 2007 21:49:37 GMT
On 7/12/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:
> >> > 6. first class support for bytebuffer storage
> >> > 7. support for IMAP requirements such as line and byte counts for parts
> >>
> >> charser/encoding conversions would be needed for ESMTP/8BITMIME support.
> >
> > 8BITMIME is an IMAP extension
> >
> > from an nio perspective, both charset and encoding would be issues
> > best left to the application. of course this then raises the
> > performance issue of executing the same decoding multiple times.
>
> I don't think that multiple conversions is a big deal. Btw we can do
> some optimization by always keep the last conversion and change only if
> strictly necessary.
> E.g: if we receive 8bitmime mail and we have to deliver via 8bitmime
> server then we can avoid conversion. If we receive 7bitmime mail we can
> avoid conversions at all.

ok

> > not sure i have an easy answer for this
> >
> >> > 8. support for meta-data
> >>
> >> can you elaborate?
> >
> > for example, JAMES attributes and javamail flags
>
> Why does this need to be implemented IN the MimeMessage handling
> structure? is this something that the MIME specification take into
> consideration? Can't we keep the Envelope/MimeMessage paradigm and place
> meta data in the envelopes ?
> This is not to say I'm against metadata, just to better understand the
> motivation behind the requirement.

that's a good question :-)

i suppose that this is also a question about API design within JAMES:
what objects do we pass to represent mail?

> >> > 9. support for outputting components of the message
> >>
> >> So, what do you keep in memory? the mime structure? And if possible
> >> pointers to streams for every parts (possibly shared) so that you can
> >> lazy parse them when you try to output them using a different encoding?
> >
> > when using a bytebuffer, everything is already in memory so this is
> > easy. doesn't sound very easy for streaming solutions though.
>
> How do we deal with 1GB mime messages?

ATM IMAP handles them badly

the torque backend stores these as a byte array. io is done via
streams. in between, the data is transfered as MimeMessage and string
buffer.

in general, this kind of parser would typically work on temporary
files. using nio, the large messages would be saved directly by the OS
to disc on the way in. the parser would then work on a memory mapped
buffer.

- 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