[2.0] Possible Breaking Changes #229
Labels
API
compatibility
integration
tech-debt
Things that needs to be tidied up to avoid being bitten in the future...
Milestone
This issue is just tracking the ideas for changes that will possibly break backward-compatibility in 2.0:
Do note that these are ideas and not concrete plans. They may -- and likely will -- change, and some might even get abandoned.
(In no particular order; the numbers are just for ease of reference. Please do not reorder, just strikeout using
~~...~~
if idea is abandoned.)Drop non-Controller-affecting kwargs, gather them in
**kwargs
**SMTP_Parameters
Enforce Command Limit unconditionally (not optionally like in 1.x)
Drop 4-arg EHLO handler and go exclusively 5-arg EHLO handler
Drop
auth_callback
and useauthenticator
exclusivelyStop misusing
MISSING
-- it should have one purpose and one purpose only: indicate no user-supplied hookDrop support for
ehlo_hook
,rset_hook
, andprocess_message
Separate support for
8BITMIME
fromdecode_data
Implement
8BITMIME
whenSMTPUTF8
is specfiedEmbed
StreamReaderProtocol
(see Stop inheriting fromStreamReaderProtocol
? #210 )Change
hostname
parameter ofController
tohost
This matches the parameter name of
loop.create_server
, and not conflicting with thehostname
parameter of SMTP, allowing pass-through of Controller's**kwargs
to SMTP. (See also No. 1 above)Use different logger for "verbose" logging, so
mail.log
contains only the most important log entries (see Introduce different loggers for different purposes #239)Handler hooks will no longer be required to return a response to clients; if a hook returns
None
(or something Falsy),SMTP
should continue as is the hook isMISSING
(see Hooks returning None should make smtp.py behave like nothing happened. #154)Uniformize Handler Hook signatures.
As we saw in Allow handle_EHLO to change the responses to EHLO #157, when we need to give more data to a handler, we're forced to implement a complex detection mechanism to determine how much args to send to the hook. If we replace each individual hook signature with, say,
(server, session, envelope, data
wheredata
is aDict[str,Any]
, if we need to send new data, we won't have to determine how many args the hook supports; just add a new key:value pair and send.Uniformize Handler Hook returns.
In concordance with No.13, how do we determine if a handler hook is "old version" or "new version"? Since the signatures are now the same, the only way is to determine the type and/or contents of the return value. Rather than having a proliferation of "specialized return classes" (as currently used by the authenticator callback) needing a bunch of
isinstance()
s, we can uniformize on aHookReturn
object, which itself can contain aversion
attribute (or similar). Based onversion
, the SMTP method implementation can process theHookReturn
object differently... or not.Decompose the
SMTP
class into base "Protocol" and "Method Classes".When instantiated, the SMTP class will perform a "composition" of SMTP Method Classes. This idea might even get extended further into a "plugin" system, allowing 3rd party "methods" to be deployed as separate packages. In a way, similar to "pytest" and "twine" and various other tools-with-plugins packages.
Don't manage the loop (run_forever, stop & close, etc.) if loop is given caller
The principle is that the caller sets up the loop, probably to run several things concurrently, and therefore will probably not appreciate it if our Controller suddenly ends the loop.
Change the name of the modules to be more semantically consistent.
For example, why is it
controller
instead ofcontrollers
if it actually contains more than one controller class? We should name it in a similar way tohandlers
Stop proliferation of parameters to
SMTP.__init__()
and pass in a "config dict" instead.Currently
SMTP.__init__()
has 18 (eighteen!) parameters. This is simply too many. If we pass in a "config dict" instead, we can simplify the class greatly.Separate AUTH methods into its own class that can be separately instantiable.
Currently,
SMTP.__init__()
need to always scan itself to find the AUTH methods. Due to howasyncio.create_server
works (it seems to re-initialize SMTP for every new connection, CMIIW), this makes SMTP initialization quite slow for subsequent connections, because we cannot maintain a ref to the AUTH methods inbetween inits. If we move the methods to a separate class, we can instantiate that class once and cache the method refs in a classvar in SMTP, saving time on subsequent SMTP connections.Similarly to No.19 above, we should also separate SMTP methods to its own class.
Exact same reason as No.19: Speeds up subsequent SMTP connections by caching method refs.
Implement more secure defaults as discussed in Docs and example suggest running aiosmtpd INSECURELY #374
In-between 1.2.3 and 2.0, additional
DeprecationWarning
s will be added to the code.The text was updated successfully, but these errors were encountered: