Hacker News Reader

Comment by jclulow | Hacker News Reader

It seems that Github should eventually retry delivery on transient faults, like connection time outs or 500 errors.

I'm surprised to see that they don't - it seems standard to retry on failure, waiting longer and longer between each attempt.

Some sort of pubsub queue would be awesome - pull (or have them pushed), and process them on demand. If something breaks, retry when you want.

Those are basically the semantics of SMTP delivery. Come to think of it, that protocol could make more sense than HTTP for asynchronously messaging entities. I love the simplicity of webhooks, but sometimes it's nice to abstract away the redelivery mechanism without having to set up one's own broker.

FWIW, that's the underlying protocol used in BlueButtonPlus[0], the proposed method for exchanging healthcare information.

[0] http://bluebuttonplus.org/transmit-using-direct.html

I'd love an open-source appliance that lets me turn webhooks (and polling APIs) into a kind of pub-sub. Being able to inspect, modify, and run events would be an "immediately use this" feature set.

It would be something I would pay for to not have to host myself, but iff there's a clear migration path, i.e. it's open-source.

Wishbone could do that http://wishbone.readthedocs.org/en/latest/index.html

Some example articles:

- http://smetj.net/processing_webhooks_using_wishbone_part_1.h...

- http://smetj.net/processing_webhooks_using_wishbone_part_2.h...

Huginn?

You should never assume that a third-party implements HTTP properly by default.

Reply on news.ycombinator.com