Mikel, the biggest thing, for me at least, in TMail 2.0 would
definitely be the interface. I recently have been wrapping it so I
could add a mailer gem to the Mack framework, and I found it terribly
confusing. It''s very feature rich, but constructing simple emails, is
a bit cumbersome, and non-intuitive.
What I''ve done for Mack is created a very simple interface for
creating emails that should be very easy for people to use and I''ve
wrapped that around an adapter to TMail.
If you''d like to look at the interface, it''s at:
http://github.com/markbates/mack-more/tree/master/mack-mailer/lib/mack-mailer/mailer.rb
The usage of it looks like this: http://gist.github.com/2712
Now, of course I''m doing a few things under the covers as far as
configuration is concerned, but the point is it should be as possible,
but allow for people to get in there and really mix it up.
Just my $.02. TMail is a great Mailing framework, but it definitely
could be easier to use. :)
-------------------------------------------------------------------------------------------------
Mark Bates
mark at mackframework.com
http://www.mackframework.com
http://api.mackframework.com/
http://github.com/markbates/mack
On Jul 26, 2008, at 10:56 PM, Mikel Lindsaar wrote:
> On Sun, Jul 27, 2008 at 3:42 AM, charles <aquasync at gmail.com>
wrote:
>> I''d be interested in helping out with 2.0. Big rewrites seem
risky
>> though, might be better if we can just push the code gradually in the
>> right direction.
>
> That''s probably a better idea and more what I meant :) I mean big
> re-write in a few key areas.
>
>> What are the main things you want to change?
>
> Specifically, probably in order of priority:
>
> * Encodings. TMail works in several cases, but there are plenty that
> it doesn''t... big5 and Chinese encodings tend to nuke it. The
encoder
> was written from a Japanese viewpoint, needs more l18n work. TMail
> should be able to send and receive any language without failures.
>
> * Ruby 1.9 compatibility. I have started on this, and it works
> somewhat. I got it down to three failing tests. The big problem here
> is that 1.9 supports encodings and 1.8 does not. Right now, TMail
> sprinkles the encoding throughout the code base (mainly contained in a
> few points... but not neat). This needs to be extracted to an
> interface and all text manipulations go through this class that
> translates the encoding in and out. This is a fairly complex job and
> is going to take probably the most work. But we have to have 1.9
> compatibility soon.
>
> * IO and speed up here. I think we can speed this up fairly well.
> Handling large mailboxes etc is a bit scary right now. I like some of
> your ideas.
>
> * Interface. TMail is too complex and does not make the simple case
> easy. You shouldn''t REALLY need to know the MIME spec to assemble
an
> email and send it. At the same time, you should be able to manually
> assemble an email if you want. Simple case easy, complex case
> possible viewpoint.
>
> * The Parse Tree. The one it is using is RACC. I haven''t yet
found
> anyone that really understands it who is willing to help out - and
> there are edge cases that it just breaks with that I have handled by
> sanitizing the input to the parser. Other parsers are available
> (Parse Tree maybe?), and it may also just be simpler to do this in
> plain Ruby split up into intelligent regex methods. Ruby regex has
> come a fair ways since TMail was written. Having our extensive test
> base would help with this.
>
> On the interface, I want to clean it up a lot. The simple task of
> sending an email with an attachment should be simple and obvious.
>
> require ''tmail''
> TMail::Mail.config({:smtp => 127.0.0.1})
>
> TMail::Mail.send do
> from ''me at me.com''
> to ''you at you.com''
> subject ''This should be easy''
> multipart true
> text_body my_plain_text
> html_body my_html_text
> add_file(''This is the first attachment'',
''/path/to/my.jpg'')
> add_file(''This is the second attachment'',
path_to_file, ''text/
> unknown-type'')
> end
>
> And it just goes ahead and builds the email and sends it, wrapping
> Net::SMTP.
>
> Receiving should be as easy....
>
>> I''d like to clean up my IO patches, and replace the (at least
it
>> seems
>> to me?) unnecessary "port" abstraction with plain IO objects.
Example
>> use case, is to create a TMail object from an arbitrary IO handle,
>> from an email in a zip (eg zip/zipfilesystem), or wherever. Maybe a
>> first step is to introduce an IOPort class.
>
> That''s a good idea. TMail has a bunch of different strategies
that it
> uses to read in email. I''d like to simplify this a bit as it gets
> really painful with encodings.
>
>> After that, I''d like to see tmail perform better with large
emails -
>> eg not holding an entire 20M attachment in memory raw, and base64
>> encoded, but using streaming and filters for encoding/decoding.
>
> Right. I think we are on the same track and I would appreciate your
> help. Anyone else on the list have suggestions?
>
> Mikel
>
>
> --
> http://lindsaar.net/
> Rails, RSpec and Life blog....
> _______________________________________________
> Tmail-talk mailing list
> Tmail-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/tmail-talk