Comments on: The Great XMPP Dispute and pubsubhubbub http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/ User-defined HTTP callbacks for push, pipes and plugins Tue, 04 May 2010 19:35:11 +0000 hourly 1 http://wordpress.com/ By: Jason Salas http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/#comment-40 Jason Salas Tue, 24 Feb 2009 23:51:48 +0000 http://blog.webhooks.org/?p=131#comment-40 Thanks! With my CMS being a web-based platform, we theoretically *could* modify the underlying system, but I think we negate our support terms...meaning if something goes awry I'm on my own (and it's in Perl, which is outside my C# knowledge). That's great advice though...thank you! Thanks! With my CMS being a web-based platform, we theoretically *could* modify the underlying system, but I think we negate our support terms…meaning if something goes awry I’m on my own (and it’s in Perl, which is outside my C# knowledge).

That’s great advice though…thank you!

]]> By: Jeff Lindsay http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/#comment-39 Jeff Lindsay Tue, 24 Feb 2009 23:46:25 +0000 http://blog.webhooks.org/?p=131#comment-39 Jason, You don't mention whether you actually have access to the code, but if you do, the core mechanism for invoking a web hook is usually a single line of code in most environments. The rest of the work is just managing the callbacks for what, but if it's a one-off solution for yourself, that makes it much easier to ping out to one endpoint in all cases, which you can just hardcode... making the end implementation literally one line to have the real-time push mechanism in place. From there you just write the code to take that data and push it to whatever protocol/channel you want. When it's a one-off solution for yourself like this... it's pretty straightforward to get something working with web hooks. However, if you don't have access to the code and there is no event API, you can use something like Gnip to turn the RSS feed into a callback (they use web hooks to push data). Jason,

You don’t mention whether you actually have access to the code, but if you do, the core mechanism for invoking a web hook is usually a single line of code in most environments. The rest of the work is just managing the callbacks for what, but if it’s a one-off solution for yourself, that makes it much easier to ping out to one endpoint in all cases, which you can just hardcode… making the end implementation literally one line to have the real-time push mechanism in place.

From there you just write the code to take that data and push it to whatever protocol/channel you want. When it’s a one-off solution for yourself like this… it’s pretty straightforward to get something working with web hooks.

However, if you don’t have access to the code and there is no event API, you can use something like Gnip to turn the RSS feed into a callback (they use web hooks to push data).

]]> By: Jason Salas http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/#comment-38 Jason Salas Tue, 24 Feb 2009 23:33:30 +0000 http://blog.webhooks.org/?p=131#comment-38 Fantastic thoughts, Jeff. A friend and I were talking about which architecture to use for building a notification system that sends out multiplatform alerts (e-mail, SMS, IM, RIA) when my web site gets updated, so of course we talked about XMPP or web hooks. We tried to base the decision in terms of the total labor involved...which is the rub. The CMS I use is a third-party product that, with the exception of an RSS 2.0 feed (not Atom), there's no public API and thus no event framework to tap into. I'd have to write a hacky workaround to emulate the publishing event (if at all possible) and wire-up the callbacks with web hooks. Or, setup an entire XMPP infrastructure with a PubSub or PEP backend and build a custom bot to listen to changes and then push out updates. I'm partial to go the web hooks route on this one, but ironically, the amount of work to do either in this situation would be about the same: a lot. :-) Thoughts? Fantastic thoughts, Jeff. A friend and I were talking about which architecture to use for building a notification system that sends out multiplatform alerts (e-mail, SMS, IM, RIA) when my web site gets updated, so of course we talked about XMPP or web hooks. We tried to base the decision in terms of the total labor involved…which is the rub.

The CMS I use is a third-party product that, with the exception of an RSS 2.0 feed (not Atom), there’s no public API and thus no event framework to tap into. I’d have to write a hacky workaround to emulate the publishing event (if at all possible) and wire-up the callbacks with web hooks.

Or, setup an entire XMPP infrastructure with a PubSub or PEP backend and build a custom bot to listen to changes and then push out updates.

I’m partial to go the web hooks route on this one, but ironically, the amount of work to do either in this situation would be about the same: a lot. :-)

Thoughts?

]]> By: Jeff Lindsay http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/#comment-34 Jeff Lindsay Mon, 23 Feb 2009 16:12:05 +0000 http://blog.webhooks.org/?p=131#comment-34 I think I can see that, but the major thing that makes it different from SUP is that it actually has a callback or hook mechanism that means you can actually be triggered or pinged instead of having to poll yet another feed. I think I can see that, but the major thing that makes it different from SUP is that it actually has a callback or hook mechanism that means you can actually be triggered or pinged instead of having to poll yet another feed.

]]> By: Julien http://blog.webhooks.org/2009/02/22/the-great-xmpp-dispute-and-pubsubhubbub/#comment-33 Julien Mon, 23 Feb 2009 15:30:06 +0000 http://blog.webhooks.org/?p=131#comment-33 Indeed, that was an interesting "dispute"... And I agree 100% that we actually need both. From a user's perspective, it's not the "pipe" that matters but the data! Anyway, As far as I understood PubSubHubhub is more like SUP (friendfeed's protocol) in its "concept" than like XEP-0060! Indeed, that was an interesting “dispute”… And I agree 100% that we actually need both. From a user’s perspective, it’s not the “pipe” that matters but the data!
Anyway, As far as I understood PubSubHubhub is more like SUP (friendfeed’s protocol) in its “concept” than like XEP-0060!

]]>