Am 30.05.2014 um 05:19 schrieb Esteban A. Maringolo <emaring...@gmail.com>:
> As promised... I tested it, and worked. Thank you again Norbert!
>
I’m glad to hear that.
> I chose Mandrill over Postmark by two main reasons (other than better
> looking UI):
> * It doesn't require me to authenticate the from address (which is
> unexistant, because it is a no-reply address, and the domain doesn't
> even have a MX server).
> * It's pretty much free (though this is not a relevant factor )
>
Well, it is 12000 emails free per month.
> Now about the strategy when sending emails from Pharo...
>
> Assuming you flag the transactions as "mailSent" or similar.
>
Mariano is referring to a piece of code I’ve sent him. This one
post
| mailResponse |
participant := self participantWithId: request uri pathSegments second.
participant hasEmail ifTrue: [
mailResponse := (MandrillMessage new
addRecipient: (MandrillRecipient new
email: participant email);
html: self emailBody;
subject: self subjectLine;
fromEmail: ProjectConfiguration fromEmail;
fromName: ProjectConfiguration fromName ) send. ].
((mailResponse first at: 'status') = 'sent')
ifTrue: [ self persistence changeStateOf: participant to:
#emailSent ]
ifFalse: [ self persistence changeStateOf: participant to:
#emailFailed ].
self emptyOkResponse
> How do you send the emails?
>
> 1.a. Right after the "transaction" (or other trigger/status) was performed?
> 1.b. Right after the transaction, but forking (#fork) the submission
> and returning immediately (to avoid waits on the client side)
> 2.a With a worker image with a loop and running indefinitely (checking
> mails in the database every n minutes)
> 2.b. Running a cron job that starts a Pharo image, does his jobs, and quits
>
> 3. Some real architecture involving some kind of live communication
> (sockets, MQ, etc.) between the image where the event was triggered
> and the worker image.
>
> 4. ?
>
> I was thinking in doing 2.
>
> Comments suggerences?
There are a lot of ways you can do that. From your description I assume you
have quite some incoming requests that should return quickly. Furthermore you
want to keep exact track of the sent email and react to unexpected cases,
right?
In my case I don’t have these requirements. The request rate is pretty low and
there is no effect to the user if a request to my handler takes longer. So I
decided to use the synchronous API from Mandrill. So I get back the status
immediately and can flag the action as OK or failed. I don’t need more because
if a message is not delivered from time to time it is no problem. So I guess
I’m in case #1
If your requirements are different I’d probably wouldn’t take the effort to do
#2. It gets complicated really quick. If we have another view on the Mandrill
API webhooks come to the rescue [1]. In your request handler you send the
message asynchronously. The status in the message is „queued“ then. If you have
the webhooks registered you get called from mandrill whenever the status of a
mail send changes. That is probably the best option because no need to poll
anything.There is no support for that in the Mandrill API at the moment. But
I’m interested in this as well and could collaborate on that.
I think #3 would be really heavy weight for the task. My advize is not to do
these kind of things until you really know that you need it. Complexity kills!
Norbert
P.S.: The code is on smalltalkhub now [2]
[1] http://help.mandrill.com/entries/21738186-Introduction-to-Webhooks
[2] http://smalltalkhub.com/#!/~NorbertHartl/Mandrill
