Write a new alert service

Is this still needed?

I don't know. If PLoS is not asking for it, I don't think so.

There still might be a need for this. Response from Russ:

with the current system, we cannot do subject category alerts, as we
have no way to assemble a custom email per user based on individual
prefs.

if fixing that requires a service, then let's have a service.

if it's easier to do this command line, i have no problem getting rid
the service (but i could be missing something)

any tool replacing the current system needs to be able to create and
send multipart (text and html) emails (but that's pretty easy) and
handle bounce detection.

maybe it makes sense to consider the general (non-plos) use case here.
how  would a small journal running topaz want it to work?

i think that running this as a service, with some kind of web
administration to generate, test, and send alerts, is probably the
ultimate goal.

This should really be an extension of the REST based RSS feeds. Any real-time performance issues with these should be resolved before this is started.

Further, while bounce detection seems straight forward on the surface, it is not.

• Need admin interface to manually turn of users
• Some users will bounce intermittently. Thus retries are necessary
• The entire concept of sending mail, retrying, throttling, etc. is non-trivial

My point is that it is not something we should try from scratch. Rather integrating with existing mailing-list type software is much preferable. The reasons we did not do this in the unused alerts service we did for launch was we didn't consider all these things and there was time pressure.

agree with the REST direction, I'll take the ticket. caching will be in the REST layer for performance. email bounce detection, etc. is hard. this should not be in the webapp, it needs to be in the email infrastructure.

Not sure this is feasible in 0.8

Milestone WishList? deleted