If you decide to build your own "hub" software, the publisher -> hub relationship is really up to you. At superfeedr for example, we implement the regular spec for this part, but also allow other protocols (XMPP, XML-RPC) or event fat pings. What matters the most is that your "compliant" on the hub -> subscriber part, as long as you run your own hub.
On Thu, Apr 28, 2011 at 7:44 PM, Justin Karneges <[email protected]>wrote: > Indeed. My thought is that the feed could know this by means other > than the mechanism described in section 7.1. For example, if AtomPub > was used to create an entry, then this could be enough for the "hub" > to push an update out to subscribers. > > On Apr 28, 12:54 am, Julien Genestoux <[email protected]> > wrote: > > Hey Justin, > > > > I don't see any reason why that wouldn't work. > > However, your "hub" will still need to know when the feed has been > updated > > to push the updates to the subscribers. > > > > Cheers, > > > > On Thu, Apr 28, 2011 at 4:45 AM, Justin Karneges > > <[email protected]>wrote: > > > > > Hi folks, > > > > > We would like to offer push callbacks to our feeds without the notion > > > of a separately addressable hub. So, for example, if we have an Atom > > > feed here: > > > > > http://example.com/feed/ > > > > > Then, one could subscribe to updates using the following: > > > > > POSThttp://example.com/feed/ > > > params: > > > hub.callback={callback_url} > > > hub.mode=subscribe > > > hub.topic=http://example.com/feed/ > > > hub.verify=async > > > > > Of course, the topic URL must always be the feed itself. The "hub" > > > would never crawl out to some external feed, nor would publishers > > > necessarily need to notify the "hub" of changes, since the feed and > > > hub are one. > > > > > Is there an example of this approach in the wild? Is this approach > > > discouraged in any way? > > > > > Thanks, > > > Justin >
