You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2001/06/20 23:11:30 UTC
Can of worms
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 Knystautas
Loki Technologies
http://www.lokitech.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Can of worms
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
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" <ch...@benett1.demon.co.uk>
>
> > 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: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: MimeMessages API
Posted by Serge Knystautas <se...@lokitech.com>.
Yes, it's part of the JavaMail API. http://java.sun.com/products/javamail/
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "John S. Gage" <jg...@epo.som.sunysb.edu>
To: <ja...@jakarta.apache.org>
Sent: Monday, June 25, 2001 8:53 AM
Subject: MimeMessages API
> Is the MimeMessages API distinct from James?
>
> John
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
MimeMessages API
Posted by "John S. Gage" <jg...@epo.som.sunysb.edu>.
Is the MimeMessages API distinct from James?
John
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Can of worms
Posted by Serge Knystautas <se...@lokitech.com>.
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" <ch...@benett1.demon.co.uk>
> 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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Can of worms
Posted by Danny Angus <da...@thought.co.uk>.
> So, I guess I come back to my question - what does MimeMessage give us?
>
> Charles
Yeah thats what I'd like to know too.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Can of worms
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org