On Mon, 22 Dec 2008 20:55:45 -0800, "Seth Fitzsimmons" <[email protected]> wrote: > 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. >
I agree. The way it was, the time-stamp was not very useful as you pointed out. I made some changes in December that have not been published yet, presumably due to Christmas breaks. In any case I just noticed that I had forgotten to update the schema, so I'll do that and ping Peter just in case ;-) The major change is that time-stamping is now optional, and individual time-stamps can be added to each beacon in the query, for instance if the client wants to collect several beacons over time before sending a single query. This *could* be useful to help saving bandwidth for people with poor mobile data-contracts. In our experience it is important for the server to be able to reconstruct a time-history of which beacons was seen by the querying user at what time. That being said, I could be persuaded to drop the time-stamp altogether. In that case the server would assume that all beacons in a query was visible to the sender at the time the query was sent, which, save transfer delays, is known to the server. >>> 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])
