Well said Bob. I agree with everything you mentioned. One nice thing about these location feeds is that they can be generated on the fly as needed. I picture subscriptions happening the way Blaine described with an optional radius field. This gives you an infinite number of feeds that can be generated with the backend of the service doing the heavy-lifting to generate matches, leaving pubsubhubbub as merely the "dumb" transport mechanism.
On Feb 1, 10:27 am, Bob Wyman <[email protected]> wrote: > On Mon, Feb 1, 2010 at 1:04 AM, Michael Barinek <[email protected]> wrote: > > hub.lat 39.51 > > hub.lon -76.24 > > If this is supposed to express a constraint on published items (a query), > what does it mean? Does it require an exact match? (If so, then I think > you'll find that very few useful applications of location data can be > satisfied with just an exact match...) Typically, one wants some radius > around a point in these applications. Thus, for this to be useful, you'd > have to add in a hub.radius value. Or, many applications will want to be > able to do things like say "east of this point" or "south of this point..." > How would that be expressed? (Or, "east of here but no more than 50 miles"?) > Consider as well that many location based applications require bounding > boxes, not just point and radius or position relative to a point. So, for > simple rectangular bounding boxes, you'd need at least two points. But, > these days, the bounding boxes that describe things like cities, towns, > counties, etc. are often expressed as polygons which require an arbitrary > number of points... How would you encode those? (Note: CAP -- the emergency > notification standard, uses polygons to describe events like earthquake > disaster zones...) And, many sophisticated applications use approaches > like Hierarchical > Triangular Mesh <http://skyserver.org/HTM>, > HEALPix<http://healpix.jpl.nasa.gov/> > , COBE Quadrilateralized Spherical > Cubes<http://lambda.gsfc.nasa.gov/product/cobe/skymap_info_new.cfm> > , Military Grid Reference System > (MGRS)<http://en.wikipedia.org/wiki/Military_grid_reference_system>or > the simpler Maidenhead > Locator System <http://en.wikipedia.org/wiki/Maidenhead_Locator_System> used > by amateur radio operators. An early adoption of a syntax for expressing > locations and constraints on locations might make later adoption of more > expressive mechanisms more difficult than it could be. > > In any case, I would argue that we shouldn't be adding type or application > specific parameters to PSHB in order to handle one-off requirements -- > especially since it is likely that we'll find that we need to combine > constraints in the future. I might want to subscribe to: > "Items published within 5 miles of here by Tom Jones that mention Pizza or > Sushi." > How would I express the boolean combination of "Location AND Author AND > (food1 OR food2)"??? > This could be very difficult if the means for expressing constraints is by > using parameters. it would be vastly easier to accomplish if we had, > instead, a textual syntax (like a query language) for expressing these > things. > > I suggest that we should be fairly careful not to move ahead with point > solutions that will either make progress more difficult in the future or > will inevitably end up with us eventually having multiple solutions to the > same problem. Let's first get the basic, simple PSHB up running and well > understood before we go too far down the road of adding complexity such as > content-based matching. > > bob wyman > > > > On Mon, Feb 1, 2010 at 1:04 AM, Michael Barinek <[email protected]> wrote: > > oh, the example in my first post may have suggested a custom url although > > lat/lon are just additional post parameters. > > > better example... > > > hub.callback http://your.hostname.com > > hub.mode subscribe > > hub.secret > > > hub.lat 39.51 > > hub.lon -76.24 > > hub.verify sync > > hub.verify_token > > > Bob Wyman wrote: > > >> There are many attributes of an item published via PSHB that one might > >> want to select on in order to build a custom feed. Location is certainly > >> one > >> of the more interesting ones. However, there are many others. For instance, > >> it would be interesting to subscribe to the work of specific authors, not > >> just feeds. Or, feeds from anyone at a particular domain (like a company), > >> or all items that contain the word "Foobar"... Certainly, URL conventions > >> could be constructed to cover many of the common cases, however, what we'll > >> end up with if we go too far down that road is a situation where many items > >> are being published in multiple feeds (wasting resource) and we'll still > >> want to have the capability to do things like subscribe to words or phrases > >> in published items. > > >> Personally, I think we should restrain ourselves from defining too many > >> URL conventions and instead think about the more general problem of doing > >> content-based subscriptions on aggregates of feeds. I think it would be > >> best > >> to leave core PSHB itself as a simple "topic-based" system with a simple > >> core subscription syntax (i.e. subscribe by feed URL only...) and a > >> mechanism to pass "firehose" feeds to more complex subscription systems. > >> Then, we should define companion specifications for systems that would > >> allow > >> content-based filtering of feeds in more complex ways. > > >> bob wyman > > >> On Sun, Jan 31, 2010 at 5:56 PM, Michael Barinek <[email protected]<mailto: > >> [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 withhttp://www.localhash.com/ > > >> Thanks
