Raffi, Is it only the account/verify_credentials method that will return the <geo_enabled> sub-element in the <user> element, or all methods that return a <user> element?
While having only account/verify_credentials return it is better than nothing, I would hope that all methods that return a <user> element would include a <geo_enabled> sub-element. For consistency, if nothing else. With the issues associated with account/verify_credentials requests and the DOS attack, I have been avoiding using the method: Basic Authentication credentials can be, and in fact are, verified with any and every authenticated request; OAuth credentials (access token and token secret) are by their nature pre-authenticated, and are, again, re-verified with each and every use. So this may require me to issue an account/verify_credentials request where I would otherwise not have to do so, just to get the <geo_enabled> flag. I can, and will if necessary, do that, but would prefer not to. Jim Renkel -----Original Message----- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, September 02, 2009 18:01 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: if you will be using the Geolocation API ... hi jim. yup! http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verif y_credentials > Raffi, > > Another question came up as I was thinking about support for this in > my web-site (http://twxlate.com): > > Will the <user> elements returned in the responses to API requests > include information that indicates whether or not the user has opted- > in to geo-coding of their tweets? > > I would like to see this right from the get go so that client web- > sites / applications know whether or not to prompt their users for > location information to be geo-coded with a tweet that is being > created. If this isn't there, I think there will be unnecessary > confusion and possibly wrong actions taken on behalf of the user. > > Please seriously consider this for inclusion in the initial > deployment, if it is not already there. > > Thanks in advance. > > Comments welcome and expected. > > Jim Renkel > > On Sep 1, 6:08 pm, Raffi Krikorian <ra...@twitter.com> wrote: >> hey jim. >> >> >> >>> 1. "the user.location is a completely separate entity (for now)" >>> implies >>> that maybe sometime in the future it may be used, e.g., to provide a >>> default geo-coded location for a tweet. I would suggest that if the >>> user's profile location if ever geo-coded, that geo-code should be >>> added >>> to the <user> objects returned by API calls, at least the users/show >>> method. Users will want to know what may be, e.g., added to their >>> tweets >>> without having to generate a test tweet to find out. >> >>> 2. Having the user's profile location geo-coded and returned in API >>> calls would be very useful now. Yeh, twitter client web-sites / >>> applications can do it for themselves (Mine certainly will if >>> twitter >>> doesn't do it.), but may come up with different / inconsistent >>> results. >>> And, trust me, it ain't as easy to get good results as it might >>> first >>> appear. To maximize use and consistency, it would be great if >>> twitter >>> did the geo-coding and supplied it to everyone. >> >> these are both great ideas. right now, the geolocation API is really >> focused on tweet-level information -- but we're actively thinking >> about what's next. >> >>> 3. Will twitter client web-sites / applications be able to turn the >>> geo-location feature on for their users, or do the users have to >>> go to >>> twitter.com with a browser to do this? My concern here is that >>> twitter.com only supports two languages (English and Japanese) for >>> its >>> UI, where my site (http://twxlate.com) supports these and over 40 >>> more. >>> Unless the user is fluent in English or Japanese, they won't be able >>> to >>> turn it on. I've already run into similar problems as I'm rolling >>> out >>> test versions of OAuth support. >> >> unfortunately not. as we're pretty sensitive to our user's privacy, >> for now, a user will have to go to twitter.com with a browser to turn >> on the setting (remember, by default it is off). if you have any >> suggestions on how to make this user interaction better in the >> future, >> i would be eager to hear them! >> >>> As I've written some pretty spiffy geo-coding applications for other >>> purposes, I plan on doing some pretty spiffy geo-coding stuff with >>> twxlate.com. But it needs to be usable, or users won't use it >>> and / or >>> may be annoyed by it. I would hate for that to happen to what >>> promises >>> to be a really neat feature. >> >> cool! well - i hope what we're doing is usable! if not, just keep >> blasting me about it. threads like these on the mailing list are >> awesome. >> >> -- >> Raffi Krikorian >> Twitter Platform Team >> ra...@twitter.com | @raffi -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
