← Back to team overview

hipl-core team mailing list archive

Re: commit mailing script

 

On 30/08/10 04:30, Mircea Gherzan wrote:

Hi,

Hi,

Christoph Viethen<viethen@xxxxxxxxxxxxxxxxx>  wrote:
Might it be possible to take the e-mails that are sent from Launchpad (in the
stupid format) and have them sent to a special mail address (like
launchpad-mailprocessor@xxxxxxxxxxxxxx or whatever else i4's Admins can come
up with) only, and not to the mailing list any more? (Does Launchpad allow to
configure that?) That way, an incoming e-mail to that special mail address
could be used to trigger your script (which would then send a pretty version
of the commit message to the hipl-core mailing list), and it would not be
necessary to have it run periodically by cron or something.

This boils down to whether an event-driven approach can be used instead of the
current polling-based one (running the script via cron).

When using an intermediary "mail processor", POP3 is not an option: there's
still an app *polling* the POP3 mailbox and then firing up the script.

So there only one alternative: using IMAP with IDLE support (push mail). Yes,
the Sun Java System Messaging Server supports this. A python/whatever script
might be continuously connected to the mail server and, upon receiving
notification of a new mail, fire up the script. However, this breaks the KISS
principle since:
* it involves yet-another script (daemon-like)
* it relies on the delivery of the mail from Launchpad and on the reliability
   of the chosen mail server
* a bzr up (followed by a bzr revno) is not that expensive, given the current
   machines.

But, if the powers that be decide it's worth, I'm willing implement this
alternative solution.

Feedback is, as usual, welcomed.

I would suggest either:

a) contributing to the launchpad email service itself (tight coupling)
b) loose coupling by implementing the email service completely independently of launchpad (i.e. polling as done by Mircea now)

I am not convinced if we really need to optimize triggering of launchpad messages (this would be something intermediate between options a and b). IMHO, the cost of extra complexity and dependency to the possibly changing details of the launchpad service may not pay off. Keep it simple!



Follow ups

References