[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-18 Thread Derek Chen-Becker
OK, I tested locally and it works for me. I just pushed to master and it
should show up in Hudson soon.

Derek

On Tue, Mar 17, 2009 at 1:52 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 OK, new code is checked in on wip-dcb-mailer-charset branch. Does anyone
 have time to test?

 Derek


 On Tue, Mar 17, 2009 at 2:39 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 This is strictly MIME, so the plain text part of the message will have
 an explicit charset associated with the text. The JavaMail framework is very
 flexible in terms of what you can send, how it's encoded, etc, but Lift's
 interface only exposes a small subset appropriate for sending either text
 emails or XHtml w/ optional images. The BodyPart interface that we're using
 doesn't directly allow you to specify content encoding, just the charset:

 http://java.sun.com/products/javamail/javadocs/javax/mail/BodyPart.html

 If you want to do more interesting things (ie send a file attachment) you
 would want to use JavaMail directly.

 Derek


 On Tue, Mar 17, 2009 at 2:31 PM, Marc Boschma 
 marc+lift...@boschma.cxmarc%2blift...@boschma.cx
  wrote:

 It depends upon what is meant by plain. According to RFC 2045 (5.2) the
 default character encoding for a non-MIME message is us-ascii and the
 transfer encoding would be 7bit.
 Given that I think we are speaking of MIME encoded messages I think that
 the default of UTF-8 is ok in a lift context, but that you should provide
 the case class as not all email clients understand UTF-8 and if building a
 message that has the widest support is desired then it should be easy to
 specify alternatives that can be interpreted.

 What is the treatment of character encoding in the interface? ie. can I
 specify base64 or quoted-printable, etc?

 Marc

 On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

 I'm looking at ticket #19:


 http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding

 The setText method is essentially a shortcut for setContent(...,
 text/plain), but it also allows you to specify the character encoding.
 Would anyone be opposed to modifying the code so that PlainMailBodyType uses
 UTF-8 for character encoding? Would it be useful to provide an additional
 case class, a la

 PlainPlusBodyType(text : String, charset : String)

 Derek





 




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Marc Boschma
It depends upon what is meant by plain. According to RFC 2045 (5.2)  
the default character encoding for a non-MIME message is us-ascii and  
the transfer encoding would be 7bit.

Given that I think we are speaking of MIME encoded messages I think  
that the default of UTF-8 is ok in a lift context, but that you should  
provide the case class as not all email clients understand UTF-8 and  
if building a message that has the widest support is desired then it  
should be easy to specify alternatives that can be interpreted.

What is the treatment of character encoding in the interface? ie. can  
I specify base64 or quoted-printable, etc?

Marc

On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

 I'm looking at ticket #19:

 http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding

 The setText method is essentially a shortcut for setContent(...,  
 text/plain), but it also allows you to specify the character  
 encoding. Would anyone be opposed to modifying the code so that  
 PlainMailBodyType uses UTF-8 for character encoding? Would it be  
 useful to provide an additional case class, a la

 PlainPlusBodyType(text : String, charset : String)

 Derek

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Derek Chen-Becker
This is strictly MIME, so the plain text part of the message will have an
explicit charset associated with the text. The JavaMail framework is very
flexible in terms of what you can send, how it's encoded, etc, but Lift's
interface only exposes a small subset appropriate for sending either text
emails or XHtml w/ optional images. The BodyPart interface that we're using
doesn't directly allow you to specify content encoding, just the charset:

http://java.sun.com/products/javamail/javadocs/javax/mail/BodyPart.html

If you want to do more interesting things (ie send a file attachment) you
would want to use JavaMail directly.

Derek

On Tue, Mar 17, 2009 at 2:31 PM, Marc Boschma
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
 wrote:

 It depends upon what is meant by plain. According to RFC 2045 (5.2) the
 default character encoding for a non-MIME message is us-ascii and the
 transfer encoding would be 7bit.
 Given that I think we are speaking of MIME encoded messages I think that
 the default of UTF-8 is ok in a lift context, but that you should provide
 the case class as not all email clients understand UTF-8 and if building a
 message that has the widest support is desired then it should be easy to
 specify alternatives that can be interpreted.

 What is the treatment of character encoding in the interface? ie. can I
 specify base64 or quoted-printable, etc?

 Marc

 On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

 I'm looking at ticket #19:


 http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding

 The setText method is essentially a shortcut for setContent(...,
 text/plain), but it also allows you to specify the character encoding.
 Would anyone be opposed to modifying the code so that PlainMailBodyType uses
 UTF-8 for character encoding? Would it be useful to provide an additional
 case class, a la

 PlainPlusBodyType(text : String, charset : String)

 Derek





 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Derek Chen-Becker
OK, new code is checked in on wip-dcb-mailer-charset branch. Does anyone
have time to test?

Derek

On Tue, Mar 17, 2009 at 2:39 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 This is strictly MIME, so the plain text part of the message will have an
 explicit charset associated with the text. The JavaMail framework is very
 flexible in terms of what you can send, how it's encoded, etc, but Lift's
 interface only exposes a small subset appropriate for sending either text
 emails or XHtml w/ optional images. The BodyPart interface that we're using
 doesn't directly allow you to specify content encoding, just the charset:

 http://java.sun.com/products/javamail/javadocs/javax/mail/BodyPart.html

 If you want to do more interesting things (ie send a file attachment) you
 would want to use JavaMail directly.

 Derek


 On Tue, Mar 17, 2009 at 2:31 PM, Marc Boschma 
 marc+lift...@boschma.cxmarc%2blift...@boschma.cx
  wrote:

 It depends upon what is meant by plain. According to RFC 2045 (5.2) the
 default character encoding for a non-MIME message is us-ascii and the
 transfer encoding would be 7bit.
 Given that I think we are speaking of MIME encoded messages I think that
 the default of UTF-8 is ok in a lift context, but that you should provide
 the case class as not all email clients understand UTF-8 and if building a
 message that has the widest support is desired then it should be easy to
 specify alternatives that can be interpreted.

 What is the treatment of character encoding in the interface? ie. can I
 specify base64 or quoted-printable, etc?

 Marc

 On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

 I'm looking at ticket #19:


 http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding

 The setText method is essentially a shortcut for setContent(...,
 text/plain), but it also allows you to specify the character encoding.
 Would anyone be opposed to modifying the code so that PlainMailBodyType uses
 UTF-8 for character encoding? Would it be useful to provide an additional
 case class, a la

 PlainPlusBodyType(text : String, charset : String)

 Derek





 



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---