Comments on: Announcing Hookah, the Web Hook Event Dispatcher http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/ User-defined HTTP callbacks for push, pipes and plugins Tue, 04 May 2010 19:35:11 +0000 hourly 1 http://wordpress.com/ By: Business Glue: Webhooks for the Enterprise « Elastic Data http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-152 Business Glue: Webhooks for the Enterprise « Elastic Data Tue, 02 Jun 2009 02:39:24 +0000 http://blog.webhooks.org/?p=155#comment-152 [...] for enabling and simplifying idempotent webhook processing. Jeff’s scriplets.org and Hookah are a great start. A worthwhile extension might be a webhook-based pubsub messaging cloud with [...] [...] for enabling and simplifying idempotent webhook processing. Jeff’s scriplets.org and Hookah are a great start. A worthwhile extension might be a webhook-based pubsub messaging cloud with [...]

]]> By: Webhooks - Samples and Usage | Technology http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-123 Webhooks - Samples and Usage | Technology Mon, 04 May 2009 06:59:48 +0000 http://blog.webhooks.org/?p=155#comment-123 [...] As you can see from the image above and some of his posts, Jeff Lindsay likes to claim that all it takes is one line of code to enable these hooks but he admits that there is more to it than that, let me pull out a quote from one of his articles on this topic. I like to claim you can implement web hooks with one line of code. The reality is you need to do mor... [...] [...] As you can see from the image above and some of his posts, Jeff Lindsay likes to claim that all it takes is one line of code to enable these hooks but he admits that there is more to it than that, let me pull out a quote from one of his articles on this topic. I like to claim you can implement web hooks with one line of code. The reality is you need to do mor… [...]

]]> By: Jeff Lindsay http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-61 Jeff Lindsay Tue, 03 Mar 2009 15:59:26 +0000 http://blog.webhooks.org/?p=155#comment-61 John, cool. Nice work with django-webhooks btw. John, cool. Nice work with django-webhooks btw.

]]> By: John Boxall http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-60 John Boxall Tue, 03 Mar 2009 06:01:40 +0000 http://blog.webhooks.org/?p=155#comment-60 Hey Jeff, The super light implementation is very interesting - when I was throwing together django-webhooks I was so focused on an implementation of generic listener / subscriber models that I didn't really consider the performance of the hooks and decided I'd just run them from a DB queue with a cron job. I'll be looking at plugging this into djhooks to make the requests real time. Thanks! Hey Jeff,

The super light implementation is very interesting – when I was throwing together django-webhooks I was so focused on an implementation of generic listener / subscriber models that I didn’t really consider the performance of the hooks and decided I’d just run them from a DB queue with a cron job.

I’ll be looking at plugging this into djhooks to make the requests real time.

Thanks!

]]> By: Jeff Lindsay http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-58 Jeff Lindsay Tue, 03 Mar 2009 00:41:11 +0000 http://blog.webhooks.org/?p=155#comment-58 Implementations might tend to be app/lang/framework specific, but I don't think they need to be, right? That's the point of this. Though it has to be written in a particular language, it is not a library, and so it doesn't require your app to be Python to use it. Also, it will eventually be much more configurable and have optional features that people would like. Whether you have a JSON payload or not may or may not matter, and if you want a queue it should at least be easy to hack if not an explicit option. Anyway, that's where I'd like it to go, which is not obvious in the code itself. So to re-iterate: it's not a library. It's a standalone daemon for use from any language. Obviously if you have something already, you don't need this. However, I'd love it if you could share lessons learned from your implementation. :) Implementations might tend to be app/lang/framework specific, but I don’t think they need to be, right? That’s the point of this. Though it has to be written in a particular language, it is not a library, and so it doesn’t require your app to be Python to use it.

Also, it will eventually be much more configurable and have optional features that people would like. Whether you have a JSON payload or not may or may not matter, and if you want a queue it should at least be easy to hack if not an explicit option. Anyway, that’s where I’d like it to go, which is not obvious in the code itself.

So to re-iterate: it’s not a library. It’s a standalone daemon for use from any language. Obviously if you have something already, you don’t need this. However, I’d love it if you could share lessons learned from your implementation. :)

]]> By: rick http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-56 rick Mon, 02 Mar 2009 21:40:15 +0000 http://blog.webhooks.org/?p=155#comment-56 I think the problem is that web hook code tends to be application, or especially language/framework specific. I'd totally share what I have, but it's barely enough for a library. For example, a ruby port of Hookah would be easy to create... but I'd want to be able to configure to send JSON, or use a queue rather than a thread that gives up after 3 tries. Adding stuff like that could turn this tidy little lib into something more complex and less attractive to drop into your app. I definitely like the ideas around this though. I think the problem is that web hook code tends to be application, or especially language/framework specific. I’d totally share what I have, but it’s barely enough for a library. For example, a ruby port of Hookah would be easy to create… but I’d want to be able to configure to send JSON, or use a queue rather than a thread that gives up after 3 tries. Adding stuff like that could turn this tidy little lib into something more complex and less attractive to drop into your app. I definitely like the ideas around this though.

]]> By: Jeff Lindsay http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-55 Jeff Lindsay Mon, 02 Mar 2009 21:24:12 +0000 http://blog.webhooks.org/?p=155#comment-55 Peter, agreed! I was going to have it callback for outgoing callback responses (a nice way to handle asynchronous response handling), but having other hooks back to your application sounds like a Good Idea. As for standardization, we're starting to talk about some of this on the GetPingd list at the moment. I'll definitely want to integrate whatever we come up with where it makes sense in Hookah. Peter, agreed! I was going to have it callback for outgoing callback responses (a nice way to handle asynchronous response handling), but having other hooks back to your application sounds like a Good Idea. As for standardization, we’re starting to talk about some of this on the GetPingd list at the moment. I’ll definitely want to integrate whatever we come up with where it makes sense in Hookah.

]]> By: Peter Keane http://blog.webhooks.org/2009/03/02/announcing-hookah-the-web-hook-event-dispatcher/#comment-54 Peter Keane Mon, 02 Mar 2009 21:14:58 +0000 http://blog.webhooks.org/?p=155#comment-54 Nice stuff. Seems like Hookah itself might callback to the calling application once it successfully does its work, for logging, etc. This might be a place to standardize a bit (and I'd suggest being RESTful and including the callback-callback url in a hypertext representation that you are posting to Hookah). Nice stuff. Seems like Hookah itself might callback to the calling application once it successfully does its work, for logging, etc. This might be a place to standardize a bit (and I’d suggest being RESTful and including the callback-callback url in a hypertext representation that you are posting to Hookah).

]]>