hi jim.
its only properly documented there (that will be fixed soon!), but all
<user> objects will have the <geo_enabled> element in it.
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
--
Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi
