-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API is potentially redundant #55
Comments
This package offers a tighter integration into the Pyramid ecosphere than |
FWIW I tend to agree that |
@tseaver I'm not sure your comment is relevant.. the OP isn't bringing up repoze.sendmail but rather the silly apis on pyramid_mailer.Mailer. |
@tseaver added me to the team for this repo a while back. I had been wanting to facilitate a release to get the debug mailer changes out. I'll take a look at this issue if I can, soon, but wanted to get feedback. How would we feel about simply |
This sounds acceptable to me but even then |
I guess I can see |
|
Sure, but isn't it still transactional? Is it really a good idea to leave it up to the caller whether the email gets send in the background or foreground? Feels like a config-time option. |
I guess that depends on the intended use. I could image wanting to process the queue mail differently. It may be bulk mail that needs to go through some tracking service that handles unsubscribe or something. It may need a different SMTP server, to ensure transactional mail doesn't end up undeliverable because your bulk mailings are getting marked as spam. On the other hand, the non-queued sends would be for transactional mail in response to direct user action. On the other hand, if that's not the intended usage, then I agree it should be a config-time option. |
Well there's no way atm to |
I'm not familiar enough with the repoze mail. Is it the case that both delivery mechanisms delay until transaction commit? |
Yeah the |
Let's be careful with the language here, too. "Transactional" has a meaning in mailing that is opposite "bulk", in addition to the meaning of "takes effect iff the transaction commits" here. I don't think we've confused this in the thread here yet, but just pointing that out for sanity. But, let's talk about transactions as in the Right now we seem to have two dimensions (and you rightly point out we are missing a quadrant): Transaction vs Non-transaction We don't have non-transactional, queued. At the least, the transaction support seems great, especially because we inherit it with little effort from the repoze package. And queue vs non-queue feels important because the mail world has this notion of transational vs bulk mail and I can see using it for that difference. But maybe that's the wrong use case and I'm wrong and this should be pure configuration. So, I think we can check the box for "remove the send_sendmail and send_immediately_sendmail" APIs. No consensus yet on anything else. Does that sound right? |
I'm going to try to resurrect this. Probably via cutting the current pyramid_mailer as 1.0 and then discussing a 2.0 API that standardizes on IMO pyramid_mailer is currently a poor abstraction because people sending email still need to think about which mailer they want - how many times should this be different in different parts of your app? I'm currently thinking about the following. class Mailer:
def send(self, message, **kw):
"""
Send a message.
By default, all options are taken from the default mailer (usually
automatically constructed from the application settings).
:param immediate: If ``True`` the message will be sent immediately
on its own transaction.
:param transaction_manager: Override the default
``transaction_manager`` bound to the mailer. This option is mutually
exclusive with the ``immediate`` option.
:param queue: If ``True`` the mail will be sent to the local queue
defined by the ``queue_path``. This will error if no ``queue_path``
has been defined.
:param queue_path: Override the default ``queue_path`` setting.
:param sendmail: If ``True`` the message will be sent using the
``sendmail_app`` and ``sendmail_template`` settings.
:param sendmail_app: The sendmail executable. This value is
interpolated into the ``sendmail_template`` argument list.
:param sendmail_template: The command-line argument list invoked.
If you just need to change the executable then set ``sendmail_app``
instead.
""" This would be accompanied by the
In general it's possible to make everything immediate if necessary because we can wrap it in a new local transaction manager and call commit - so any delivery mechanism that is transactional can be made immediate. Does anyone have anything to say about this idea? |
👍 |
This doesn't restrict any flexibility but it means most people, most of the time, can just call |
I generally like the idea of consolidating everything within a single
fwiw our typical use-cases:
It might be nice to provide for an abstract API based email delivery class in the future. |
It seems to me that repoze.sendmail has an SMTP mailer and a sendmail mailer. Both implement
IMailer
. Why does pyramid_mailer create both and expose itself as a wrapper around both with separate API functions?Is there a common deployment scenario where one application would want to use both methods to send mail?
It seems to me that this just creates incompatibilities where some module authors will get the mailer and call
send()
while others will callsend_sendmail()
.Would it not be better to choose, by configuration, which mailer is used, so that module authors can just call
send()
and the deployment can choose which is used?The text was updated successfully, but these errors were encountered: