Seth Fitzsimmons wrote: > Hey. > > Is this the right list for comments on this XEP? > > For example, Section 10.1 refers to the wrong namespace and Example 7 > contains some extraneous ''s. 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". Helge (cc'd) will check out the extraneous '' stuff. Thanks for the heads-up. > 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. 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. > 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. Client implementations are out for Symbian S60 with iPhone and Android clients in the works. S. -- Simon Tennant Buddycloud uk: +44 20 7043 6756 de: +49 89 420 955 854 uk: +44 78 5335 6047 de: +49 17 8545 0880 email and xmpp: [email protected]
