0.2.0 Branch

[eugene-eeo]

@rslinckx would you mind checking out the 0.2 branch? With this branch I basically wanted to correct the wrongs that were present in 0.1.0, and make Mailthon a better library. These changes were made:

• Envelope is now a wrapper over Enclosure objects. This means that the mail_from and rcpt_to addresses can be set without subclass hackery. Also, no more unnecessary multipart emails which (take up a little more bandwidth due to the need for boundaries) unless required.
• Enclosure objects now have a sender and receiver property, as well as a string method which means they can be sent via the Postman class.

I was about to add pluggable transports and replace the Postman class with something like Session and Transport but I don't really know if that's useful since I don't swap out the transports that often.

Also do you think that Middleware should have a setup and teardown method instead of just __call__? This will make it far easier to teardown temporary resources that might have been allocated in the life of the middleware.

cc @mrleeh, @kootenpv

[rslinckx]

It looks great !

Regarding pluggable transports, i don't think there's a need for that at this stage.

Regarding Middleware, maybe there should be some kind of event system (before_connect, before_logout, etc) and middle ware are just subscribers to these events ?

[eugene-eeo]

@rslinckx thanks for reminding me of the hooks pattern, I will implement it once I ironed out the bugs and work out how to embed images :smirk:

Update: Might seem stupid/straightforward but this was actually quite a hassle to do because I had to manually set the "Content-ID" header. This can now be done easily:

b = Binary(open('spacer.gif').read(), 'image/gif')
b.content_id('spacer')

[eugene-eeo]

Progress Update: Sorry for the lack of progress, was really demotivated and bogged down by exams for a while. :sweat_smile:

• Response((status_code, message)) => Response(status_code, message), uses namedtuples underneath.
• Worked on the tests so that they're more understandable.
• High level APIs remain unchanged.

IMHO most of mailthon is already quite stable and solid. Currently I am thinking of extracting the mime-handling part out into a separate package, so that mailthon focuses on SMTP and wrapping stuff around the mime-handling library.

@rslinckx can you recommend/step up as a maintainer? I am unable to actively maintain it for the coming half-year or so due to A-levels.