Skip to main content

Home/ Web2.0/ Group items tagged PubSubHubbub

Rss Feed Group items tagged

Graham Perrin Proposed Salmon Protocol Aims To Unify Conversations on the Web - 1 views

  • October 17, 2009
  • Proposed
  • Unify Conversations on the Web
  • ...21 more annotations...
  • conversations that occur on downstream aggregation sites
  • parallel discussions on the originating Web site
  • services, including JS-Kit's Echo and Disqus
  • pulling external discussions to the source
  • Salmon Protocol
  • unify the conversations
  • upstream and downstream
  • in all places
  • An Initial Presentation
  • conversations where they are comfortable
    • Graham Perrin
      I'm most comfortable in Diigo.
  • multiple downstream destinations
  • leverages the newest iteration of webfinger
  • fractured conversations
  • send the new comments to the site which is lacking the full conversation
  • could cause confusion
  • implied (all data is public)
  • a test playground for the Salmon Protocol
  • turn this brand-new protocol into a new standard
  • a serious challenge to services like JS-Kit Echo and Disqus
  • including threaded replies
  • the long debate over unified conversations could soon be over
Graham Perrin

Unifying the Conversations (Salmon Protocol) - 7 views

  • Salmon Protocol
  • Unifying the Conversations
  • protocol for comments and annotations to swim upstream to original update sources
  • ...4 more annotations...
  • commentary in a virtuous cycle
  • user centric
  • demo running at the Salmon Playground
  • presentation: Salmon Real Time Commenting FlowSalmon Real Time Commenting Flow
Graham Perrin

DevHawk - The Last Mile of the Internet - 5 views

  • August 27, 2009
  • The Last Mile of the Internet
  • NAT/Firewall issue makes any async messaging based approach useless for clients
  • ...9 more annotations...
  • Polling sucks. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today
  • a fundamental design that looks like this: This picture leaves out multiple publishers and subscribers and the subscriber registration process, but you get the basic idea
  • fine for server subscribers (like, say Google Reader) but not for client subscribers (like, say TweetDeck).
  • the only way to enable client subscribers to play in this async messaging world is via some type of relay service
  • In this approach, the client subscriber makes an outbound connection to some type of relay infrastructure
  • technically feasible
  • Yes, having to relay messages sucks. But the question is
  • which sucks worse: polling or relaying?
  • Harry Pierson
Graham Perrin

Superfeedr Blog : Getting Started with PubSubHubbub - 1 views

Graham Perrin

ComparingProtocols - pubsubhubbub - Comparison of PubSubHubbub to light-pinging protoc... - 0 views

  • Comparison of PubSubHubbub to light-pinging protocols
  • concrete differences between fat pinging (PubSubHubbub, XMPP pubsub) and light pinging (rssCloud, XML-RPC pings, changes.xml, SUP, SLAP)
  • core difference
  • ...4 more annotations...
  • how new information from feeds is delivered from a publisher to a subscriber
  • Light pings: Send the URL of the feed that has updated to the subscriber. Fat pings: Send the updated content of the feed to the subscriber
  • Green is good, red is bad
  • criteria to consider for each protocol
Graham Perrin

pubsubhubbub - Project Hosting on Google Code - 0 views

  • reference implementation
  • protocol
  • publish/subscribe
  • ...10 more annotations...
  • server-to-server
  • extension to Atom and RSS
  • web-hook-based
  • The protocol in a nutshell
  • hub(s) can be run by the publisher
  • or can be a community hub
  • If the Atom file declares its hubs
  • avoid lame, repeated polling
  • multicasts the new/changed content out to all registered subscribers
  • decentralized
Graham Perrin

PubSubHubbub FAQ - Google Moderator - 1 views

  • We envision people adding one line to their blog XML feeds
  • immediate participants in the pubsub world
  • simplifies things so much in almost all real-world use cases
  • ...3 more annotations...
  • using Atom
  • We love XMPP and we love REST
  • we love things actually working, even if it's not 100% ideal
Graham Perrin

Draft: PubSubHubbub Core 0.2 -- Working Draft - 0 views

  • PubSubHubbub Core
  • 0.2 -- Working Draft
  • base profile is HTTP-based
  • ...8 more annotations...
  • Polling sucks
  • decentralized pubsub layer
  • fundamental
  • missing layer in the Internet architecture
  • looking forward to decentralized social networking
  • Aggregated Content Distribution
  • Aggregated Content Distribution When a subscriber indicates the same callback URL is used for multiple subscriptions, hubs MAY choose to combine content delivery requests into a single payload containing an aggregated set of feeds.
  • Example aggregated feed
Graham Perrin

7.4 aggregated Content distribution - Pubsubhubbub | Google Groups - 0 views

  • aggregated Content distribution
  • the client model for processing a single vs. aggregated distribution might be quite a bit different
  • nervous about the whole notion of PuSH co-opting <source> for its own purposes
  • ...20 more annotations...
  • provenance
  • when you copy an entry from any feed document other than that feed document whose metadata is in the entry's atom:source
  • no way to indicate from which feed document you copied the entry unless you insert some extension element
  • it *is* important to know not only the source feed but *also* where you found the entry
  • Atom spec didn't envision this use case
  • atom:source is almost, but not quite, what's needed
  • confusion is understandable
  • something like a psh:provenance element
  • most recent context
  • like atom:source
  • not aggregate at the PubSubHubbub level until you've proved that
  • (a) you have to
  • (b) multipart/related won't cut it
  • the PSHB use case *was* frequently discussed in the Atom WG
  • pretty much what FeedMesh was intended to provide
  • to show provenence, you need to add an extension element
  • war stories about multipart/related and batching
  • skeptical about ease of subscriber implementation
  • This thread is a great example of peer review
  • I'll file an issue in the bug tracker
1 - 9 of 9
Showing 20 items per page