You could certainly have TMail have a concept of SMTP/POP3 if you wanted 
to wrap it up in a helper method, but all I really mean is to be able to 
write the message to an IO (/Port) like object, for streaming to file, 
socket etc. Eg:

  Net::SMTP.start('...') do |smtp|
    smtp.open_message_stream, '...', ['...'] do |io|
      tmail.write io
    end
  end

And similarly:

  open('mymail.eml', 'w') { |f| tmail.write f }

Like you say though, this is maybe possible with the Ports abstraction 
that exists currently (though I must admit I'm not sure what Ports 
really adds over just using regular IO object interfaces.)

What doesn't seem to be possible is to chain filters in a lazy streaming 
way on top of ports. I'd like to be able to write this kind of thing:

  part = TMail::Mail.new
  part.content_type = 'text/html'
  part.body = open('test.html')
  tmail << part
  part = TMail::Mail.new
  part.content_type = 'application/octet-stream'
  part.body = Filter::Base64.encode open('mydata.bin')
  tmail << part
  ...

The idea is that Filter::* classes wrap encoding and decoding in a 
streaming way, by just providing #read / #write etc. Then you can send 
mails with 50Mb attachments (don't ask ;) without having to read the 
whole thing into memory.

Similarly, you should be able to open a mail, ask for a binary 
attachment, and get an IO-like object, that is really a 
Filter::Base64.decode wrapped substream in the file.

I've got streaming filters that I wrote before for a ruby pdf lib 
(base64, hex, ascii85 etc), that do this kind of thing.

Anyway, kind of a long email, but if you're interested I could maybe 
come up with some patches to move things in that direction....

Charles

Mikel Lindsaar wrote:
> On Jan 16, 2008 3:17 PM, Charles Lowe <aquasync / gmail.com> wrote:
>> This is great news! No more action_mailer when all you really want is
>> tmail.
> 
> Heh.. that's exactly how I got myself into the corner of becoming the
> maintainer :)
> 
>> I wonder though - something I came up against before - is there a way to
>> attach a large binary file (using ports?) without reading it in its
>> entirety first? Ideally, you could just point the attachement to an IO
>> object, set the associated filters (eg base64), and then get it to
>> stream it to disk / smtp server.
> 
> Good idea.  Though TMail itself has no concept of SMTP or POP3 or any
> other protocol really, it just handles the mail object headers really.
>  Doesn't touch the body.
> 
> It makes sense, I guess we would have to give a TMail::Mail object to
> be able to accept a Net::SMTP object and wrap it (much the same way we
> do with TMail::Mail.load)
> 
> Have you played much with the ports area?  To be brutally honest, it
> is something I am only starting to dive into, I have been
> concentrating on getting all the existing tests passing (which they
> all do now in trunk, for 1.9 and 1.8.6) and getting all the address
> and header parsing working (which a lot more works now than it did
> before) and finally documentation (there is a LOT more docs than there
> was in 0.9).
> 
> Now that we have 1.9 compatibility wrapped I want to focus more on
> adding more documentation and fixing any other bugs for the 1.2
> branch.  But I would love a hand if you want to give it a shot.  We
> need some more TMail developers I think :)
> 
> My ideal scene for TMail would be being able to just define the mail
> object, give it a Net::SMTP connection and say "go send thyself" and
> it handles the rest.
> 
> But need some more hands for that :)
> 
> Mikel

-- 
Posted via http://www.ruby-forum.com/.