I don't really see why this has to be explicitly defined in the spec. Can't the hub just publish a feed (at some arbitrary hub-specific URL) that combines any subset of the feeds that the hub watches, and let clients subscribe to that? They might want to require authentication, of course, but I'm still not seeing why this requires special support in the protocol.
--Ravi igrigorik 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 >
