1.9 Compat and merging mail gem into ActionMailer

[Mikel Lindsaar]

Hi all of both RoR Core and TMail.

You may know me better as the maintainer of TMail.

However, TMail has been a bit difficult to get working with Ruby 1.9,
so in the light of that, I sat down over the past few months and wrote
myself an all encompasing mail gem.  Mail passes all of its hundreds
of specs equally well in Ruby 1.8.6, 1.8.7 and 1.9.1.  Mail reads
every email in the TMail test suite without crashing, and is designed
to never crash on parsing input (I know, can't really say that, but it
is very resilient to crap).

The point is that TMail is _not_ 1.9 compatible and is _hard_ to get
compatible.  Mail is compatible, however needs some more work to make
it a TMail replacement.

I announced it on Ruby-Talk on the 25th of you are interested, "[ANN]
mail 1.0.0"  You can get mail from gemcutter, or from
http://github.com/mikel/mail

But this email is to solicit help and testing of a rewrite of
ActionMailer to use the installed mail gem instead of the bundled
tmail lib/vendor.

I have forked ActionMailer at:
http://github.com/mikel/rails/tree/master/actionmailer/ and I welcome
help / testing / code on getting this done.

Mail is "very" ruby.  And we can abstract a LOT of code out of
ActionMailer that is already written (or should be written) into Mail.
 Part handling for example, attachments, nesting multipart/report
handling, all is in Mail itself... no need for actionmailer to
duplicate it.

With very little code changes to ActionMailer, I am down to about 79
errors / failures, most of these are highlighting areas I need to
improve mail itself, which is fantastic.  But with a bit of help, we
can knock this over very fast.

Mail is doing fairly well.  It needs some refactoring, but I am
expecting several .x releases over the next weeks as we refactor and
get it working with ActionMailer.

Any comments / suggestions, all welcome.

--
http://lindsaar.net/
Rails, RSpec and Life blog....

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

[wycats]

This sounds really cool. I'll take a careful look at it next week. Is there anything specific you could use help with?

-- Yehuda

On Sat, Oct 31, 2009 at 12:15 PM, Mikel Lindsaar <raasdnil@...> wrote:

Hi all of both RoR Core and TMail.

You may know me better as the maintainer of TMail.

However, TMail has been a bit difficult to get working with Ruby 1.9,
so in the light of that, I sat down over the past few months and wrote
myself an all encompasing mail gem.  Mail passes all of its hundreds
of specs equally well in Ruby 1.8.6, 1.8.7 and 1.9.1.  Mail reads
every email in the TMail test suite without crashing, and is designed
to never crash on parsing input (I know, can't really say that, but it
is very resilient to crap).

The point is that TMail is _not_ 1.9 compatible and is _hard_ to get
compatible.  Mail is compatible, however needs some more work to make
it a TMail replacement.

I announced it on Ruby-Talk on the 25th of you are interested, "[ANN]
mail 1.0.0"  You can get mail from gemcutter, or from
http://github.com/mikel/mail

But this email is to solicit help and testing of a rewrite of
ActionMailer to use the installed mail gem instead of the bundled
tmail lib/vendor.

I have forked ActionMailer at:
http://github.com/mikel/rails/tree/master/actionmailer/ and I welcome
help / testing / code on getting this done.

Mail is "very" ruby.  And we can abstract a LOT of code out of
ActionMailer that is already written (or should be written) into Mail.
 Part handling for example, attachments, nesting multipart/report
handling, all is in Mail itself... no need for actionmailer to
duplicate it.

With very little code changes to ActionMailer, I am down to about 79
errors / failures, most of these are highlighting areas I need to
improve mail itself, which is fantastic.  But with a bit of help, we
can knock this over very fast.

Mail is doing fairly well.  It needs some refactoring, but I am
expecting several .x releases over the next weeks as we refactor and
get it working with ActionMailer.

Any comments / suggestions, all welcome.

--
http://lindsaar.net/
Rails, RSpec and Life blog....

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mikel Lindsaar]

On Sun, Nov 1, 2009 at 9:56 AM, Yehuda Katz <wycats@...> wrote:
> This sounds really cool. I'll take a careful look at it next week. Is there
> anything specific you could use help with?
> -- Yehuda

I think the biggest "gotcha" on any mail library is the handling of
multibyte character sets and encoding and decoding therewith.
Especially when you are trying to stay 1.8...1.9 compatible.

So that is where my energy is being focused now, and where I would
appreciate any help.

In terms of the ActionMailer integration, the trick is going to be
separating out what is domain specific to actionmailer, and what is
domain specific to mail.  My real goal is to make Mail an Email DSL,
and it is pretty close now.  ActionMailer shouldn't really have
anything like quoting.rb, part.rb, part_container.rb, or worry about
delivery of email, or fetching of email... there shouldn't be any call
to Net::SMTP or POP3 or the like from ActionMailer for example.

Even doing things like Base64 Encoding in ActionMailer can be
delegated to the Mail gem.  Mail is almost at the point where it will
intelligently encode anything it finds if it is not US-ASCII, in the
body, or in the headers.

Of course, you can over ride this in Mail by sending it US-ASCII
strings (ie, pre encoded to the encoding of your choice) and then add
your content-transfer-encoding, but this shouldn't be needed for
something like ActionMailer.

Anyway, I think the goal is to separate the domains between
ActionMailer and Mail.  This will clean up ActionMailer a lot (which
is a bit of a neglected child really) and provide a clear separation
to the mail gem.  It would even make it possible for people to
"require 'other-mail'" gem instead if that floats their boat.  Right
now, it is TMail or nothing.

Mikel

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

[wycats]

Very cool.

I completely agree with your perspective; I wrote the original merb-mailer, which was a tiny extension to Merb's AbstractController. José Valim recently made ActionMailer work with the new AbstractController, freeing it from concerns like layouts and helpers.

It would be nice to figure out what the abstraction point really was. Are you available on GTalk? I'm wycats@.... I'd love to chat.

-- Yehuda

On Sun, Nov 1, 2009 at 12:19 AM, Mikel Lindsaar <raasdnil@...> wrote:

On Sun, Nov 1, 2009 at 9:56 AM, Yehuda Katz <wycats@...> wrote:
> This sounds really cool. I'll take a careful look at it next week. Is there
> anything specific you could use help with?
> -- Yehuda

I think the biggest "gotcha" on any mail library is the handling of
multibyte character sets and encoding and decoding therewith.
Especially when you are trying to stay 1.8...1.9 compatible.

So that is where my energy is being focused now, and where I would
appreciate any help.

In terms of the ActionMailer integration, the trick is going to be
separating out what is domain specific to actionmailer, and what is
domain specific to mail.  My real goal is to make Mail an Email DSL,
and it is pretty close now.  ActionMailer shouldn't really have
anything like quoting.rb, part.rb, part_container.rb, or worry about
delivery of email, or fetching of email... there shouldn't be any call
to Net::SMTP or POP3 or the like from ActionMailer for example.

Even doing things like Base64 Encoding in ActionMailer can be
delegated to the Mail gem.  Mail is almost at the point where it will
intelligently encode anything it finds if it is not US-ASCII, in the
body, or in the headers.

Of course, you can over ride this in Mail by sending it US-ASCII
strings (ie, pre encoded to the encoding of your choice) and then add
your content-transfer-encoding, but this shouldn't be needed for
something like ActionMailer.

Anyway, I think the goal is to separate the domains between
ActionMailer and Mail.  This will clean up ActionMailer a lot (which
is a bit of a neglected child really) and provide a clear separation
to the mail gem.  It would even make it possible for people to
"require 'other-mail'" gem instead if that floats their boat.  Right
now, it is TMail or nothing.

Mikel

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---