Comments on: PubSubHubbub (PuSH), Google and Buzz http://blog.gnip.com/pubsubhubbub-google-buzz/ Social media data tracking, updates from Twitter, Facebook, and other publishers, Gnip product updates, and more. Mon, 09 Jan 2012 18:39:42 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Jud http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-120 Jud Fri, 19 Feb 2010 16:36:16 +0000 Thanks for the perspective on the batch stuff. Yea, I'm of mixed mind on it. It's convenient and expected on the PuSH subscriber front, *but* it breaks some of the nice and flat elegance of the hub impl for handling subscriptions. One of the nice things about PuSH is that it distributes that load out to the subscriber. As for the inconsistencies in event delivery. Stoked you guys have introspection into the pipeline; nicely done. Buzz only, and I suspect they're PuSH Publisher (e.g. Buzz) related. I can only speak on a macro level at the moment, but I'm seeing traffic patterns (event delivery) that aren't what I'd expect. Put another way, spikes at times that don't appear to follow "normal" social messaging application usage patterns; thus, delivery feels off. When I get to more honed analysis and can point to a specific, I'll let you know what I find. Thanks for the perspective on the batch stuff. Yea, I’m of mixed mind on it. It’s convenient and expected on the PuSH subscriber front, *but* it breaks some of the nice and flat elegance of the hub impl for handling subscriptions. One of the nice things about PuSH is that it distributes that load out to the subscriber.

As for the inconsistencies in event delivery. Stoked you guys have introspection into the pipeline; nicely done. Buzz only, and I suspect they’re PuSH Publisher (e.g. Buzz) related. I can only speak on a macro level at the moment, but I’m seeing traffic patterns (event delivery) that aren’t what I’d expect. Put another way, spikes at times that don’t appear to follow “normal” social messaging application usage patterns; thus, delivery feels off. When I get to more honed analysis and can point to a specific, I’ll let you know what I find.

]]> By: Eric Marcoullier http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-119 Eric Marcoullier Fri, 19 Feb 2010 05:33:35 +0000 Glad to see that there's talk about a "firehose" subscription on the list. +1 to that idea. Glad to see that there’s talk about a “firehose” subscription on the list.

+1 to that idea.

]]> By: Brett Slatkin http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-118 Brett Slatkin Thu, 18 Feb 2010 19:28:17 +0000 Hey Jud, Thanks for the post and the feedback! Batch subscription is something people have requested before; we've left it out because we're trying to keep the core spec as simple as possible (do one thing, do it well). As Josh said, it's easy to issue lots of subscription requests in parallel. Going forward I think the ideal solution to this is some kind of "firehose" subscription convention in the Hubbub spec. I know that Ilya (http://igvita.com/) and others really want this as well, and overall it would be cheaper/easier for hubs to maintain (as long as the data is 1. all public, and 2. the subscriber is fast). There's been a bit of discussion on the PubSubHubbub mailing list about this and hopefully it's something we'll iron out in the next couple months. Otherwise, could you describe further the latency inconsistencies you're seeing for event delivery? Was this for all feed sources or only Buzz? We have end-to-end probes for verifying publishing/delivery latency in the hub over time and it's been pretty solid. Let me know how I can help track down what you're seeing. -Brett Hey Jud,

Thanks for the post and the feedback!

Batch subscription is something people have requested before; we’ve left it out because we’re trying to keep the core spec as simple as possible (do one thing, do it well). As Josh said, it’s easy to issue lots of subscription requests in parallel.

Going forward I think the ideal solution to this is some kind of “firehose” subscription convention in the Hubbub spec. I know that Ilya (http://igvita.com/) and others really want this as well, and overall it would be cheaper/easier for hubs to maintain (as long as the data is 1. all public, and 2. the subscriber is fast). There’s been a bit of discussion on the PubSubHubbub mailing list about this and hopefully it’s something we’ll iron out in the next couple months.

Otherwise, could you describe further the latency inconsistencies you’re seeing for event delivery? Was this for all feed sources or only Buzz? We have end-to-end probes for verifying publishing/delivery latency in the hub over time and it’s been pretty solid. Let me know how I can help track down what you’re seeing.

-Brett

]]> By: Josh Fraser http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-117 Josh Fraser Thu, 18 Feb 2010 19:14:26 +0000 http://code.google.com/p/pubsubhubbub/issues/entry i'll leave you to add it since i've not taken the time to duplicate the issue myself. http://code.google.com/p/pubsubhubbub/issues/entry

i’ll leave you to add it since i’ve not taken the time to duplicate the issue myself.

]]> By: Jud http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-116 Jud Thu, 18 Feb 2010 19:10:49 +0000 thanks for the feedback! I took a quick glance at where to submit a bug, but didn't find the right place. pls either fwd me the URL, or submit; either way's great for me. thanks for the feedback! I took a quick glance at where to submit a bug, but didn’t find the right place. pls either fwd me the URL, or submit; either way’s great for me.

]]> By: Josh Fraser http://blog.gnip.com/pubsubhubbub-google-buzz/comment-page-1/#comment-115 Josh Fraser Thu, 18 Feb 2010 19:00:12 +0000 awesome. i'm stoked to see you guys poking around with this. it's a great direction for gnip. i like it! yeah it would be nice if PuSH supported bulk subscriptions, but from what i understand they decided to leave this out of the core spec because it's actually kindy tricky to implement on the hub (although i can't say for sure). at eventvue we used multi-curl to send the requests in parallel. it may not be ideal, but it worked pretty well. have you filed an official bug yet about the returned success code for batch requests? if not, i'm happy to add it. thanks for posting this. hopefully someone else can chip in about the reason multiple subscriptions aren't supported right now. awesome. i’m stoked to see you guys poking around with this. it’s a great direction for gnip. i like it!

yeah it would be nice if PuSH supported bulk subscriptions, but from what i understand they decided to leave this out of the core spec because it’s actually kindy tricky to implement on the hub (although i can’t say for sure). at eventvue we used multi-curl to send the requests in parallel. it may not be ideal, but it worked pretty well.

have you filed an official bug yet about the returned success code for batch requests? if not, i’m happy to add it.

thanks for posting this. hopefully someone else can chip in about the reason multiple subscriptions aren’t supported right now.

]]>