Here are the slides from Gluecon http://www.scribd.com/doc/32403557/Building-real-time-updates-for-the-Graph-API
Feedback is welcome ! On May 25, 8:36 am, [email protected] wrote: > Revision: 358 > Author: monica.keller > Date: Tue May 25 08:36:30 2010 > Log: Revised language of proposal to make it more clear. Input is > welcome.http://code.google.com/p/pubsubhubbub/source/detail?r=358 > > Modified: > /wiki/Pshb_OAuth2.wiki > > ======================================= > --- /wiki/Pshb_OAuth2.wiki Wed May 19 18:43:01 2010 > +++ /wiki/Pshb_OAuth2.wiki Tue May 25 08:36:30 2010 > @@ -1,47 +1,43 @@ > #summary Proposal for making PubSubHubbub more generic and social > > -= Introduction = > -At f8 Facebook launched a first version of real time updates for the Graph > API. These updates allow consumers to subscribe to users of their > application and get notified via an HTTP Post when the data has changed so > they can go and fetch it by invoking the Graph API endpoint. > - > -Some in the community were wondering why the PubSubHubbub protocol was not > used and be concerned about issues like the Thundering Herd. > - > -It comes down to these three reasons: > - > -= Details = > - > - 1. The need for simple data modeling of any resource: > - * PubSubHubbub currently only supports Atom and RSS and we > wanted to use JSON to match the rest of the Graph API so developers don't > have to write additional wrappers. > - * We need to syndicate changes to any type of resource, not just > feeds or lists. The changes may include updating properties of a given > resource or deleting the resource altogether. PubSubHubbub only supports > appending to the list. > - * The ability to do light pings where only the notification is > sent. Not all the use cases require fetching the data right away but can > still benefit from the notifications model as opposed to continous polling. > - > - 2. The need for user authorization > - * We needed to let users remain in control over what data is > shared and with whom based on their privacy settings. > - * Facebook is committed to authenticity and quality and there > are rules to encourage this. > - So one of the main reasons why we could not use traditional > PubSubHubbub is that it does not address authenticating the publishers or > the subscribers to determine the quality of data being pushed in or the > trust that the user has in the consumer. > - * As you may have seen, the Graph API is extremely powerful in > its simplicity, flexibility and efficiency. > - To query the Graph API you just need to figure out the url of > the resource you are interested in fetching and use OAuth 2.0 > - Ex:https://graph.facebook.com/ciberch/feed?token=XXXXwe > wanted to use a similar elegant approach for subscribing to notifications > - > - 3. The need for a more efficient content propagation architecture. > - * For those of you who are not familiar with the term, > PubSubHubbub is a open protocol which allows exchange of news feeds in real > time by POSTing changes to subscribers as they occur (this methodology is > called web hooks). One of the main goals of PubSubHubbub is to allow the > syndication of public feeds to any party. It works best when the same > content is requested by a multitude of subscribers. For example CNN's feed > would benefit from publishing to a hub that can help them service all their > consumers. The publisher and the hub do not know or worry about how the > information will be resyndicated. PubSubHubbub is built with small > publishers and large hubs in mind which allow publishers to fan out. It is > definitely a far superior to consumers polling publishers directly. > - > - > -For more details and diagrams see: > http://montrics.blogspot.com/2010/05/facebooks-realtime-updates-use-c... > += Introduction = > + > +At f8, Facebook launched a first version of real time updates for the > Graph API. These updates allow consumers to subscribe to users of their > application and get notified via a HTTP Post when the data has changed so > they can go and fetch it by invoking the Graph API endpoint. > +Some in the community were wondering why the PubSubHubbub protocol was not > used; it comes down to these three reasons: > + > += Details = > +1. The need for simple data modeling of any resource: > + * PubSubHubbub currently only supports Atom and RSS and we wanted to > use JSON to match the rest of the Graph API so developers don't have to > write additional wrappers. > + * We need to syndicate changes to any type of resource not just feeds > or lists. The changes may include updating properties of a given resource > or deleting the resource altogether. PubSubHubbub only supports appending > to the list. > +2. The need for user authorization > + * We needed to let users remain in control over what data is shared and > with whom, based on their privacy settings. > + * PubSubHubbub v 0.3 does not address authenticating the publishers or > the subscribers. > + > + * As you may have seen, the Graph API is extremely powerful in its > simplicity, flexibility and efficiency. > + * To query the Graph API you just need to figure out the url of the > resource you are interested in fetching and use OAuth 2.0 > + > + * Example:https://graph.facebook.com/ciberch/feed?token=XXXXand we > wanted to use a similar elegant approach for subscribing to notifications > +3. The need for more granular synchronization commands. > + * Since we are modeling objects and connections we need to be able > to instruct subscribers when the object is deleted or updated and needing > replacement. > + * We also want to have the option to do light pings as some of our > consumers may want to batch changes to fetch together. > + > + > +While some of these details are Facebook specific, others can benefit a > wider audience, in particular: service providers with users and APIs. With > that in mind, here is our wish list: > > == PubSubHubbub Wishlist == > - > -1. Supports the use of OAuth 2.0 for authenticating the subscriber and > publisher. > - > -2. Moves discovery of the hub to the HTTP layer by making it an HTTP Header > - - Leaves backwards compatibility for existing discovery mechanism. > - > -3. Supports data in any arbitrary format including JSON > - > -4. Supports more synchronization changes than those which can be supported > with Atom and POST > - - Includes PUT for replacing a resource and DELETE for asking that the > resource gets deleted > - - Also includes the ability to specify different end points which > receive DELETE notifications and PUT notifications > +1. Support the use of OAuth 2.0 for authenticating the subscriber and > publisher. > + > +2. Move discovery of the hub to the HTTP layer by making it an HTTP Header > + * Leaves backwards compatibility for existing discovery mechanism. > + > +3. Support data in any arbitrary format including JSON > + > +4. Support more synchronization changes than those which can be supported > with Atom and POST > + * Includes PUT for replacing a resource and DELETE for asking that the > resource gets deleted - Also includes the ability to specify different end > points which receive DELETE notifications and PUT notifications > > == Proposed Initial Spec Changes == > - > -http://github.com/ciberch/pshb_oauth > +http://github.com/ciberch/pshb_oauth > + > + > +For more details and diagrams see: > http://montrics.blogspot.com/2010/05/facebooks-realtime-updates-use-c...
