Does anyone know what the reason for parseing messages into MimeMessage
objects is? surely the Mime status of a message contents would be a private
matter for mail clients or interested mailets only, and the mail protocols
would only be interested in mail rfc822 messages.
In which case creating MimeMessage objects should be the province of
mailets, and to do so at a lower level must be unnecessary extra load?
By the same token a web app should process the message if it needs to, not
rely on James to process _every_ message just-in-case it is useful.
..IMHO..
danny
> -----Original Message-----
> From: Harmeet [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 16, 2001 5:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Remove model attribute from MailRepositories
>
>
> +1 to remove Model attribute.
>
> Mail Repository is a bit slow. While profiling POP3 I realized the Mail
> files are parsed into Java MimeMessage objects repeatedly. It may also be
> useful to store mime attachements and alternatives separatly from
> the Main
> message. This would allow a web application (JSP etc) to send the
> text(wireless device) or html(browser) body without needing to parse the
> message.
> Does this make sense ?
> I am a bit out of cycles but if someone were to do this, I would
> be happy to
> buy bear or lunch.
>
> Harmeet
> ----- Original Message -----
> From: "Charles Benett" <[EMAIL PROTECTED]>
> To: "Java Apache Mail Server" <[EMAIL PROTECTED]>
> Sent: Friday, June 15, 2001 7:25 AM
> Subject: [VOTE] Remove model attribute from MailRepositories
>
>
> > I've a couple of ideas for improving MailStore, MailRepositories etc.
> > but first I have a question:
> >
> > Does anyone have any use for the model attribute of MailRepository?
> >
> > If not, I propose to get rid of it. This would simplify things quite a
> > bit. As well as making the code more readable.
> > So, Mail Repositories would have two (functional) attributes: URL
> > (whichincludes protocol eg file or jdbc) and type (currently MAIL or
> > SPOOL)
> >
> > Votes?
> >
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
