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

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
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.


> 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

Reply via email to