Hi Julien,

Having thought about I had a few conclusions. Being an implementor (loves me 
code ;)), it would certainly be simple to do so no complaints there. I was 
curious how you saw this operating in a synchronous mode of subscription - the 
more indirect requests needed, the longer we're keeping Subscribers waiting. 
I'm particularly sensitive to us engaging in transactions which will start 
hitting bottlenecks like PHP's maximum execution time limit (let alone whatever 
the locally set HTTP timeout is). I nearly always favour async mode (where 
possible) but most Subscribers I suspect won't want the added complexity and 
will prefer synchronous.

The privacy issues I really don't see. Use of any technology is always subject 
to the client exposing something of their identity. The exposure of certain 
details like their callback URL doesn't seem to be much of an issue. By 
definition it's already publicly exposed so what else is there to keep private? 
We're not looking for Joe Doe's name, address and credit card details ;). Why 
don't we apply this same principle to Hubs? Aren't Subscribers handing them 
private information in this case already??

At the end of the day, I really think this has a huge amount of potential with 
is underplayed by its very modest intent. I think that's the main weak spot of 
the proposal - it's very specific ;). Then again, its specific nature is what 
makes it simple to grasp and implement. For myself, I would definitely like to 
see Publishers being able to get some kind of feedback in real-time in this 
vein. It may not be foolproof but on a personal note, I already have some funky 
programming tampering with my feeds so certain IPs get a feed full of copyright 
infringement messages instead of my actual content. Surely a modest blogger 
like me can't be the only one plagued by content stealing.

There is absolutely no reason why we should be linking the nature of feeds to 
the nature of Pubsubhubbub - they may be marginally related but both offer two 
very different distribution methods that merely share a common distributable 
format. It seems quite acceptable that Publishers have the right to impose 
additional restrictions. They can already do it to some extent with feeds, but 
real-time data and interactions with a Hub offers a far richer environment to 
work within.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative





________________________________
From: Julien Genestoux <[email protected]>
To: Pubsubhubbub <[email protected]>
Sent: Wed, January 20, 2010 10:28:46 AM
Subject: [pubsubhubbub] Publisher Callback Extension to PubSubHubbub


Hey,

We (superfeedr) have been in talks with a lot of publishers and several of them 
where concerned about the "blindness" for publishers in the PubSubHubbub 
protocol.

Sorry for linking from the Superfeedr blog 
(http://blog.superfeedr.com/Extension/PubSubHubbub/Spec/publisher-callback-extension/),
 but if you're looking for more insight on why we're proposing this, you can 
find it there.

We published the Extension proposal to the wiki : 
http://code.google.com/p/pubsubhubbub/wiki/AcceptingSubscriptionForPublishers?ts=1263982978&updated=AcceptingSubscriptionForPublishers

I'd love to have everybody's opinion. Bob added a few comments and I'd like to 
insist on the fact that this doesn't solve any copyright issue. It just makes 
it a little easier for publishers to know about who subscribed to their content.

I'd love to know what you guys think :). Please help me complete that!

Cheers


--
Julien Genestoux,

http://twitter.com/julien51
http://superfeedr.com

+1 (415) 830 6574
+33 (0)9 70 44 76 29
Sent from Milan, MI, Italy 

Reply via email to