Serge Knystautas wrote:
>
> 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.
I suspect we are both talking about the same thing. Give it a go and see
what happens.
Charles
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
