>     Is there a way for Wordpress users to disable this? Since Wordpress has 
> an internal hub, I'm seeing one potential side-effect.  Some sites (e.g. 
> techcrunch) use both Wordpress and FeedBurner.
>
>     Since FeedBurner already uses the appspot hub, there are now two hub 
> references in the feed. Depending on which one you subscribe to you're going 
> to get completely different content.  One which will come directly from 
> Wordpress without any of FB's analytics added (since I can only assume that 
> WP is handling feedcontent internally, and not HTTP-retrieving its own 
> content), and one from Appspot, which has been modified by FeedBurner.
>
>     This kind of issue is only going to get progressively worse as more and 
> more services implement PuSH.
>
> I'd say this is mainly a problem with FeedBurner, not WordPress.
>
> Feed proxy services should do it like this: 1) subscribe to the source
> feed with URL X, 2) publish updates using the proxy's hub (or a
> user-configured hub if desired) on URL Y, 3) have blog services
> advertise URL Y as their feed URL for subscribers. Then subscribers
> will only pick up the proxied feed and there will be no conflict.
>
> In the case of FeedBurner, I know the guys on that team are actively
> working to fix this problem. Does that solution make sense to you,
> Jay?
>
>     We've discussed this internally several times as well.  My stance is that 
> any service which modifies and republishes the feed should be scrubbing any 
> hub references from previous sources.  I think that's in agreement with what 
> you said -
>
> Wordpress publishes feed with WP hub
> Feedburner pulls feed from WP, modifies feed, removes WP hub, adds Appspot 
> hub with new 'self' href.
> Users see only one option to subscribe to, which has the content containing 
> all modifications.
>
> To make updates fastest, FB (etc.) should implement hub chaining so that 
> updates aren't poll-based, but this also has problems if a third-party hub is 
> inserted by the publisher (e.g. Superfeedr), because they're likely polling 
> content post modification.  It leads to a chain-loop.

I agree with you that in practice it's easiest if the proxy strips out
any source-feed hubs. This is especially true in a multi-datacenter
scenario where proxied feeds may not be consistent in all geographies
(thus only the overriding hub could have a complete picture of the
feed).

However, I don't like how this reduces the control of the publisher
over how they syndicate their content. It'd be nice if the originating
hub could be used for syndicating the proxied content as well. To do
that with PuSHPress, you'd have to configure the plug-in to also allow
for the proxied URL to be pushed through that hub, right?

What do you all think?

-Brett

Reply via email to