The only place I see a true need for MimeMessages are in the mailets and
matchers. Theoretically we could use some other API (that doesn't involve
parsing the entire message) to get the message data, but I think the
MimeMessage API is well known and appropriate for mailets and matchers.
The reason not to use a MimeMessage is pretty clear, but simple...
performance and memory usage.
I favor the approach of a load-on-demand MimeMessage where you use a handle
to the actual data, and only if you need something within the message do you
parse it. If you have another approach on how this should work, I'm all
ears.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Charles Benett" <[EMAIL PROTECTED]>
> Serge Knystautas wrote:
> >
> > I've got the JDBC repository pretty much working, but it's forced me to
open
> > a can of worms I was hoping to avoid. The approach isn't perfect, so
maybe
> > someone has suggestions (or tell me it isn't worth it).
> >
> > I'm trying improve on the "MimeMessage" that only instantiates parses
the
> > stream when accessed. This already exists and was JamesMimeMessage.
This
> > class does 4 things:
> > 1. In all accessor methods, it will parse the stream into a MimeMessage
(if
> > not already parsed)
> > 2. In all setter methods, it will parse the stream (if needed), and flag
> > that the message was modified.
> > 3. Provide an isModified() method
> > 4. Provide a few convenience methods including getMessageSize()
> > (MimeMessage.getSize() returns the size of the content, not including
> > headers), getLineCount(), and writeContentTo(OutputStream).
> >
> > So far, so good.
> >
> > I tried to change a couple of things though:
> > 1. Merge the EnhancedMimeMessage features into the JamesMimeMessage.
most
> > methods were already implemented, and the ones that weren't could just
be
> > copied over. Unfortunately this changed a lot of the IMAP code.
> > 2. Change how it references an InputStream. Previously JamesMimeMessage
was
> > given an InputStream, and it would read this once to parse. I wanted to
> > allow getInputStream() to work without parsing the message. This
requires
> > having a resetable InputStream. I changed the approach then to have
> > JamesMimeMessage take a MessageSource object. This source object can
open
> > multiple inputstreams to the same message data.
> >
> > I like this because you can stream data from SMTP into a "mimemessage"
> > (though not parse it) and then into a repository. Or read from one
> > repository into a "mimemessage" (again, not parsing it) and into another
> > repository.
> >
> > My problem is storing an inputstream to database requires that you know
the
> > length. This means what I'll have to do (from SMTP for instances, when
you
> > don't know the length of the message), is stream it to a temp file, then
> > stream it into the database from there. I think this is an ok
workaround as
> > it doesn't create transaction problems, but it does create a bunch of
extra
> > disk writing.
> >
> > I hope to commit tonight if the brain is still working.
>
> Serge,
>
> I think you may have been closer with your mail of 17 May, when you
> talked about reducing the use of MimeMessage.
>
> Why do we need JamesMimeMessage - or MimeMessage? Can we eliminate them
> completely?
>
> For example, can we amend Matt's SizeLimitedSMTPInputStream to provide
> the message size and Line count? That virtually eliminates the need for
> MimeMessage.
>
> Ideally, when a message is received by the SMTP server, it would extract
> the following:
> a) SMTP 'envelope': MAIL FROM, RCPT TO, remote host (which we do
> already), Auth status, SSL status
> b) Message size in ocets (incl. headers), line count.
> c) The rfc822 'envelope' per the IMAP spec (includes subject, from,
> sender, to, cc, bcc, reply-to, in-reply-to and message-id) or the full
> headers.
>
> These would be passed around with either an input stream or a byte
> array(ie an extention to Mail - with a writeTo(outputStream) method).
>
> So, I guess I come back to my question - what does MimeMessage give us?
>
> Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
