On Sun, Jan 31, 2010 at 4:02 PM, Blaine Cook <[email protected]> wrote: > On 31 January 2010 22:56, Michael Barinek <[email protected]> wrote: >> I'm not sure if location based "topics/feeds" have been discussed in the >> past, but here's something else that I've been playing around with. >> >> I've been including 'hub.lat' and 'hub.lon' parameters in subscription >> requests and then filtering inbound feeds by location (when available). >> >> for example... >> >> hub.callback=http://your.hostname.com&hub.lat=39.51&hub.lon=76.24 >> >> I'd be interested in getting feedback - interesting, not interesting, >> doesn't fit...type stuff? >> >> Here's a small application spike (still rough around the edges) that I've >> been playing around with http://www.localhash.com/ > > This sort of thing is definitely what I'd hoped would happen with > PubSubHubbub, and have been advocating in the context of XMPP PubSub > for some time! Yay! > > On the subscriber side, it's not really necessary to encode the > lat/lon into the URL, since you really should be keeping a record of > the subscription locally (if not, you're vulnerable to a number of > attacks that are much easier to manage with a subscription record). > Instead, store the filters internally and do the filtering as you > would normally, possibly including an opaque identifier as a pointer > to the filter. > > If possible, a more robust and efficient approach would be for the > service provider to offer feeds (i.e., topic URLs) that accept the > lat/lon parameters as part of the subscription. So, instead of > subscribing to: > > "http://geoprovider.com/feed.atom"; > > you'd subscribe to: > > "http://geoprovider.com/feed.atom?lat=39.51&lon=76.24"; > > and the provider (or, in many cases, the hub by virtue of fetching the > provider's feed) would take the responsibility of only sending > relevant atom entries.
And the huge benefit of this approach is that the PubSubHubbub protocol does not need to change at all to support this-- you only need a hub/publisher that's intelligent enough to interpret the subscription URLs properly.
