Watercoolr, Pubsub using WebHooks(watercoolr.nuklei.com)
watercoolr.nuklei.com
Watercoolr, Pubsub using WebHooks
http://watercoolr.nuklei.com
10 comments
Have you checked out PubSubHubbub project?
http://code.google.com/p/pubsubhubbub/
It looks like there's a lot of overlap with the feature set you need, as well as the advantage of some extra documentation + testing. It's a Python WSGI app, instead of Sinatra/Rack, and the data over the wire is encoded as Atom, but there could be some useful lessons to work from at least.
http://code.google.com/p/pubsubhubbub/
It looks like there's a lot of overlap with the feature set you need, as well as the advantage of some extra documentation + testing. It's a Python WSGI app, instead of Sinatra/Rack, and the data over the wire is encoded as Atom, but there could be some useful lessons to work from at least.
No I haven't, but I am now, thanks. (This is a particularly hard problem domain to google for)
What happens if some the subscriber can't be reached? What if delivering takes to long? Why should the server do the distribution? A "post message" could return a list of subscribers, instead. More work for the client, but more transparency, too.
Why is this interesting? I'm obviously missing something...
Any context/description/commentary?
From what I can understand, it could be useful in launching a DoS :/
Any context/description/commentary?
From what I can understand, it could be useful in launching a DoS :/
Well I wrote it because I needed a way for programs to announce what they were doing and have other subscribing programs react accordingly. The closest solution I found to this was http://xmpp.org/extensions/xep-0060.html, but that didn't seem implemented yet so I wrote the simplest thing that could work.
Cool. Seems like there should be some security to prevent abuse though, otherwise surely I could just add a ton of subscriptions to pages on a target site, and start getting your server to DoS them?
Perhaps have it look for an 'allow' file on the destination first, and if it's not there, don't send any further messages?
Perhaps have it look for an 'allow' file on the destination first, and if it's not there, don't send any further messages?
That's an interesting way to handle the auth problem, I'll look into it...
+1 vote for pubsubhubbub
The allow file idea is interesting, but we've been talking about it on the webhooks list (as well as the GetPingd list). The pubsubhubbub guys are also thinking about it (since they haven't addressed it either yet).