Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tag Libraries Developers List" <taglibs-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
In-Reply-To: <F9926D32A30ED511B8E30050044AB52E033159FF@ams010.satama.com>
To: "Tag Libraries Developers List" <taglibs-dev@jakarta.apache.org>
Subject: RE: New version of Mailer tag
MIME-Version: 1.0
Message-ID: 
 <OFD0A090CA.FDD4049B-ON80256FFD.0041B667-80256FFD.0041E710@kissint.co.uk>
From: pete.storey@kisstechnologies.co.uk
Date: Tue, 10 May 2005 12:59:50 +0100
Content-Type: multipart/alternative;
 boundary="=_alternative 0041E70A80256FFD_="

--=_alternative 0041E70A80256FFD_=
Content-Type: text/plain; charset="US-ASCII"

One other odd thing I've noticed with the old tag (and my version, and 
probably this one too), is that the part ID of the mime part gets 
incremented by JavaMail every time it sends an email so if the server has 
been running for a while you'll end up with 
boundary="----=_Part_10000_14761595.1115726191897" etc.  Isn't really a 
problem I can see at the moment but could it be on a large scale system?
cheers
Pete


"Vianen, Jeroen van" <jeroen.van.vianen@satama.com>
10/05/2005 07:56
Please respond to "Tag Libraries Developers List"
 
        To:     Tag Libraries Developers List 
<taglibs-dev@jakarta.apache.org>
        cc: 
        Subject:        RE: New version of Mailer tag


Hi Pete, 

> -----Original Message-----
> From: pete.storey@kisstechnologies.co.uk
[mailto:pete.storey@kisstechnologies.co.uk] 
> Sent: maandag 9 mei 2005 20:02
> To: Tag Libraries Developers List
> Subject: RE: New version of Mailer tag
> 
> Ah ha yes this will do it though it's a slight prob for us (and probably
> 
> others) in that it isn't backwards compatible with the mailer v1 tag so
you can't just plop it into your current implementations (and we have a 
lot
already existing).  Also can't run on Tomcat 4.x which again we (and 
others)
use a lot.

I deliberately broke backwards compatibility to make it easier to 
implement
the HTML / plain text parts and the signing and encrypting of e-mails.

> One random thought looking at it - why are the attachments a
multipart/related part of another part?  Doesn't this mean you don't see
them if you have a text only (but mime compliant) browser?  I would have
thought it would be better to have say a "related" tag which puts in
multipart/related things such as images for an HTML email, which returns a
CID, and then a seperate generic attach tag to do normal attachments in a
multipart/mixed format?

The normal way would be (I guess) to have either the following:

<mt:mail type="multipart/alternative">
                 <mt:part type="text/plain">...</mt:part>
                 <mt:part type="text/html">...
                                 <mt:attach />
                 </mt:part>
</mt:mail>

Where the attachments are only relevant for the HTML version of the 
message
(and therefore multipart/related).

Or the following:

<mt:mail type="text/html">
                 ...
                 <mt:attach/>
</mt:mail>

Where you have a plain text mail with attachments (multipart/mixed).

Regards,


Jeroen

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


email protected and scanned by AdvascanTM - keeping email useful - 
www.advascan.com 


--=_alternative 0041E70A80256FFD_=--