I don't think this should be in the spec, but a 'super hub' might use some existing pubsub model (amqp or xep-60 f.ex) to generate synthetic feeds with their own endpoints downstream. People wanting that hub's firehose could discover and connect to those as normal (atom wrapper), or as per a future fat ping discovery model tbd.
On Tue, Oct 20, 2009 at 4:22 PM, igrigorik <[email protected]> wrote: > > Right, so how does the smart hub aggregate the feeds? Does it then > have to crawl to find the list? That wouldn't be very useful. Having > said that... > > +1 For 'smart, aggregating hub generating a synthetic feed' > +1 For XRD discovery of the firehose endpoint. > > Thinking a bit more about the firehose, what about making it more > flexible. Specifically, if we treat 'firehose' as any bundle of feeds > (all, or some), then a hub could define multiple firehose streams. For > example, at PostRank we classify feeds by topic, so if someone wanted > to subscribe to "Technology", we could expose that as a firehose so > the user doesn't have to subscribe to every feed in that topic. In > essence, a firehose stream is then any bundle of feeds. > > This may be overloading the hub spec but the overall mechanics would > be: > - A (super)user can declare a firehose endpoint > - A (super)user is then able to add or remove subscriptions from the > firehose to create arbitrary aggregation streams > - A subscriber uses XRD to discover the available aggregation streams > - Firehose with 'all' feeds is a special case of the above, where all > feeds are present > > This definitely adds more complexity into the hub... The alternative > is of course for the publisher to create a syndicated feed and publish > that directly as a standalone feed. Still trying to weight the up/ > downsides in my head, but want to put it out there as an idea. > > -------- > Ilya Grigorik > postrank.com
