Consider using tink_multipart

[kevinresol]

No description provided.

[benmerckx]

This would be great. The differences that come to mind are a 76 character line limit and we need to be able to set additional headers for every chunk.

[kevinresol]

What is the line limit? Can we just split it while piping?

[benmerckx]

I wasn't completely correct, the rfc says:

There are two limits that this specification places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

Split while piping should work, while inserting CRLF after every 78 characters.

[kevinresol]

we need to be able to set additional headers for every chunk.

Ok now it should be able to construct arbitrary parts,

[benmerckx]

I'll give this a go next week. Thinking of eliminating the tink_await dependency and the queue too.

[benmerckx]

This is on its way in the next branch. I removed await dependency, added base for proper testing, attachments are now streaming and changed the api so it's not dealing with an internal queue, and it's easier to deal with connection errors.

SmtpMailer.connect({
  host: 'localhost',
  port: 1025
}).next(mailer ->
  mailer.send(email).next(
    _ -> mailer.close()
  );
);

There's more to do so leaving a note for future me:

• Properly encoding from/to headers, adding cc, bcc etc (see mtwin tools)
• Structure MultipartEncoder more like a mail builder which outputs a RealSource (possibly split into another lib) (see also https://nodemailer.com/extras/mailcomposer/) - it could take an 'Email' object for ease of use
• Implement quoted printable encoding (or keep mtwin dependency)
• Inline attachments

[ConfidantCommunications]

I noticed that both smtpmailer and tink_multipart have advanced a fair bit beyond their last haxelib releases (0.4.0 and 0.3.0 respectively). Are the git versions stable?

[benmerckx]

Ever since using lix I've not really been updating haxelib releases to be honest. I am using current master instead of haxelib releases in production.

[cedx]

@benmerckx Can you at least consider creating Git version tags? I'm not very comfortable using "insert git ref" releases...

[benmerckx]

@cedx done. Released to haxelib too.

[cedx]

Thanks a lot!