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. b.
