Responding to both Simon and Helge inline. >> I'm also confused by the presence of a (mandatory) timestamp in >> Example 2. If it's indeed a geocoder (which that section mostly seems >> to describe), there's no relevant timestamp to return. > > Timestamp-ing location queries help with averaging out errors over time. > Timestamp-ing is particularly useful for phones that only return the > primary cell-tower they are connected to rather than all the towers they > can "see".
> The time-stamp, is as Simon pointed out, only useful when a client > caches several queries and sends off in a batch. Is there scenario > where this is useful? Perhaps not. The better way to use timestamps > would probably be to add one to each beacon, and let the query timestamp > represent the GPS coordinates (if any). Then it would be possible for the > client to read different types of beacons (cells, wifi, bluetooth) and GPS > coordinates at different rates, and not loose any timing information. I will > make some changes here (maybe as a first just set the timestamp optional > and add a comment that the server can assume current time on reception) I'm still confused here. What time does the timestamp actually refer to? The time at which the query was made (which is already known to the client and can be matched using iq ids)? Or the time at which the data (on the server side) was initially collected (which is typically unavailable)? I can understand including a timestamp when updating with a set of beacons and a GPS-derived point, but the source for that would be the client side. If the intent is to match batch queries w/ asynchronous responses, I think request ids (repeatable in responses from the server) would be a better fit than timestamps. >> This is quite interesting though. When Blaine and I built out Fire >> Eagle's PubSub service, we intentionally decided not to use XEP-0080, as >> we considered it lossy and not the best fit for this application. I'll >> revisit that and try to remember specifically why that was the case; my >> initial reaction is that multiple levels of precision didn't fit and >> there was no room for additional elements like WOEIDs (although I >> suppose that could fit in the URI field). > > Keen to hear more on why XEP-0080 didn't work for you. At the moment we > do a best-effort of populating the entire place stack when a user's > location changes. At very least a lat & long with an accuracy element. > Possibly a stupid question where I should know better but what are WOEIDs? > In any case i would be interested to hear your thoughts on XEP-0080. It is > not the optimal stanza for the task perhaps, but we decided it would be > better to pick a standard shoe and force our foot into it, than to make our > own ;-) WOEIDs are Where On Earth IDs, which Yahoo! uses to refer to places (since places can have many names, varying geometries, etc.). More info here: http://developer.yahoo.com/geo/guide/concepts.html#woeids GeoNames has a similar set of identifiers used for the same purpose: when I say "États Unis" I also mean "United States" but if I want to avoid being ambiguous, I can use 23424977. See our docs on querying a user's location for our response format: http://fireeagle.yahoo.net/developer/documentation/querying XEP-0080 doesn't work for us because we want to provide more detailed information about each level of the location hierarchy (place stack). In particular, WOEID (again, uri works), potentially more detailed names, arbitrary metadata set by the application, and that level's geometry. The geometry is the sticking point: if a user has set an exact position, it can be represented as a point, but that user is also in a country, which is represented as a bounding box. We want to expose all of these geometries to applications so that they can make best use of the data available. Would returning a stack of XEP-0080 location records for an individual user be an appropriate use? > We think that this would be useful later for things like a weather bot > that the user can subscribe to: bot subs a users location then pushes > weather info as the user moves around the country/world. See http://fireeagle.yahoo.net/widgets for a non-XMPP implementation of this. >> Does anyone have client or server implementations of this yet (or intend >> to)? If so, we should talk. > > We have been fine tuning the Buddycloud Location Butler (server > component) for over a year now. Are you doing anything to restrict subscription access (i.e. location privacy)? We've found that using OAuth per XEP-0235 has worked out well. If it's feasible, I'd like to see Fire Eagle exposing its users' location information in the same way. seth (jid: [email protected])
