[twitter-dev] Re: Getting tweets from Twitter API
From what I understand, it is UTC time. The +/- is the offset depending on what zone you are in. This allows for a time value that is the same across the world, but can be offset for any particular locale. I think http://en.m.wikipedia.org/wiki/Coordinated_Universal_Time will explain it adequitly. You can also read in the time value from the API and compare it to the time shown on Twitter.com. Then change your preferences to alter your time zone. This is a good way to see how the offsets work as you go. -- Scott Iphone says hello. On Jul 10, 2009, at 10:30 PM, praveen kumar praveen.neteli...@gmail.com wrote: The time field returned contains the offset (usually +) What is the meaning of this is it GMT+0 or System time. can u please explain it. On Fri, Jul 10, 2009 at 12:39 PM, Kevin Mesiab ke...@mesiablabs.com wrote: The time field returned contains the offset (usually +) Tue Apr 07 22:52:51 + 2009 On Thu, Jul 9, 2009 at 7:13 PM, praveen kumar praveen.neteli...@gmail.com wrote: Hi, If we are getting tweets from Twitter API , User's tweet dates are in which timezone. Is it in GMT or else different timezones. -- Regards, Praveen Kumar.N -- Kevin Mesiab CEO, Mesiab Labs L.L.C. 208-447-6016 http://www.mesiablabs.com http://www.plsadvise.com -- Regards, Praveen Kumar .N Software Engineer Netelixir e-Marketing Solutions Hyderabad www.netelixir.com
[twitter-dev] User Search API
Are there plans to implement user search in the API (http:// twitter.com/search/users?q=)? Thanks! Samir
[twitter-dev] Bug with nonce value? Keeping it constant works for getting Request Token.
I just started to work toward incorporating OAuth with my application BigTweet using Perl. I have been following the excellent documenation at http://oauth.net. Jesse Stay's article at http://staynalive.com/articles/2009/05/19/social-coding-how-to-code-twitters-oauth-using-netoauth-and-perl/ was also very helpful. To the credit of the resources above, I was able to make a successful fetch of a Request Token on my first try.I began playing with the parameters to show that I could cause an error result. I discovered that I could keep the value of the nonce constant (I'm using a) and still fetch new Request Tokens. According to the spec at oauth.net it seems that the intent of the nonce was to be a unique random string for each request to help prevent replay attacks. Did I discover a bug? Thanks, - Scott @scott_carter http://bigtweet.com
[twitter-dev] Re: Streaming API -- New objects in markup stream. Test your code
Hi John,
I can't find such thing as a status or delete object in the JSON feed.
There is indeed a status enveloppe in the XML, but the corresponding
JSON object seems to be already one level deeper, only encapsulating
the data from the status itself.
Could you please clarify what we should be expecting to see in JSON ?
And maybe also provide some sample objects in the Wiki, both for XML
and JSON ?
Thanks !
-Laurent
On Jul 10, 8:00 pm, John Kalucki jkalu...@gmail.com wrote:
Note: The Streaming API is currently under a limited alpha test,
details below.
Please test that your Streaming API clients can handle unexpected
objects in the markup stream. Status deletion notice support is being
added, but will be disabled until at least Thursday July 16th to allow
developers a chance to check their code. From the
wiki,http://apiwiki.twitter.com/Streaming-API-Documentation:
Streams may also contain status deletion notices. Clients are urged to
honor deletion requests and discard deleted statuses immediately.
* XML: deletestatusid1234/iduser_id3/user_id/
status/delete
* JSON: { delete: { status: { id: 1234, user_id: 3 } } }
Objects other than status and delete may be introduced into the
markup stream in a future release. Please ensure that your parser is
tolerant of unexpected objects.
Important Alpha Test Note:
The Streaming API (aka Hosebird) is currently under an alpha test. All
developers using the Streaming API must tolerate possible unannounced
and extended periods of unavailability, especially during off-hours,
Pacific Time. New features, resources and policies are being deployed
on very little, if any, notice. Any developer may experiment with the
unrestricted resources and provide feedback via this list. Access to
restricted resources is extremely limited and is only granted on a
case-by-case basis after acceptance of an additional terms of service
document.
-John Kalucki
twitter.com/jkalucki
Services, Twitter Inc.
[twitter-dev] Other languages / Autres langages.
ENGLISH VERSION: Hello, Is it possible to have Twitter in French languages, thanks. I could translate (it take some times of course). Have a nice day. JLOX FRENCH VERSION / VERSION FRANÇAISE: Bonjour, Serait-il possible d'avoir Twitter en Français, merci. Je pourrai faire une traduction (cela prend du temps bien sur). Bonne Journée. JLOX
[twitter-dev] Re: Should consumer token be kept secret?
No, there's really not a good solution for open source developers. :( On Jul 10, 3:57 pm, Cameron Kaiser spec...@floodgap.com wrote: After reading that thread, it seems there is no good solution :( That is also my conclusion. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --
[twitter-dev] Re: Streaming API -- New objects in markup stream. Test your code
Laurent,
There are examples of the new objects on the Streaming API wiki. The
XML and JSON formats are, sadly, not orthogonal. The objects aren't
flowing to give developers time to adjust. We'll probably enable this
in the middle of next week.
-John
On Jul 11, 12:34 am, Laurent Eschenauer laurent.eschena...@gmail.com
wrote:
Hi John,
I can't find such thing as a status or delete object in the JSON feed.
There is indeed a status enveloppe in the XML, but the corresponding
JSON object seems to be already one level deeper, only encapsulating
the data from the status itself.
Could you please clarify what we should be expecting to see in JSON ?
And maybe also provide some sample objects in the Wiki, both for XML
and JSON ?
Thanks !
-Laurent
On Jul 10, 8:00 pm, John Kalucki jkalu...@gmail.com wrote:
Note: The Streaming API is currently under a limited alpha test,
details below.
Please test that your Streaming API clients can handle unexpected
objects in the markup stream. Status deletion notice support is being
added, but will be disabled until at least Thursday July 16th to allow
developers a chance to check their code. From the
wiki,http://apiwiki.twitter.com/Streaming-API-Documentation:
Streams may also contain status deletion notices. Clients are urged to
honor deletion requests and discard deleted statuses immediately.
* XML: deletestatusid1234/iduser_id3/user_id/
status/delete
* JSON: { delete: { status: { id: 1234, user_id: 3 } } }
Objects other than status and delete may be introduced into the
markup stream in a future release. Please ensure that your parser is
tolerant of unexpected objects.
Important Alpha Test Note:
The Streaming API (aka Hosebird) is currently under an alpha test. All
developers using the Streaming API must tolerate possible unannounced
and extended periods of unavailability, especially during off-hours,
Pacific Time. New features, resources and policies are being deployed
on very little, if any, notice. Any developer may experiment with the
unrestricted resources and provide feedback via this list. Access to
restricted resources is extremely limited and is only granted on a
case-by-case basis after acceptance of an additional terms of service
document.
-John Kalucki
twitter.com/jkalucki
Services, Twitter Inc.
[twitter-dev] OAuth: Screen name returned with access token - documented feature?
I noted that the screen name (and user id) are returned along with the Access token and secret. It this a documented feature that I can rely upon? The only related thread that I found on this topic was: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/8b24ab7dbb326d5f/10e6b73bd9fdce69 That thread was apparently referring to the callback after authorization and why screen_name and user_id were removed for security reasons. Matt mentioned that the verify_credentials method was the solution in that case. If I have the screen_name available with the Access token/secret, I don't see a need for calling verify_credentials at all in the process. I don't really need the screen name until after I exchange my request token for an access token. Can I rely on getting the screen_name this way? Am I missing another reason for needing to call verify_credentials? Thanks, - Scott Carter @scott_carter http://bigtweet.com
[twitter-dev] Re: User Search API
Samir, User search is something we would like to offer in the future through the API. The project is not highly ranking on the current overall roadmap, so there is no ship date to report. Thanks, Doug On Fri, Jul 10, 2009 at 2:53 PM, SamirR samir.ray...@gmail.com wrote: Are there plans to implement user search in the API (http:// twitter.com/search/users?q=)? Thanks! Samir
[twitter-dev] Going all the way back -- the 3200-tweet limit is annoying / frustrating
I've been talking with some of my Twitter friends in the Portland area and they / we are somewhat frustrated by the fact that we can only retrieve the most recent 3200 tweets via the API. I can't speak for everyone, but when I started on Twitter, it was a smallish phenomenon, known to some of the big names in the blogging world (not me) and to people interested in Ruby and Rails (me). In fact, some of those big names openly criticized Twitter for a variety of reasons. But Twitter has evolved into a business communications tool. Given that, we need tools to track our conversations, archive them, manage them, etc. Given the API, I can build tools like that, and I'm sure many other developers can as well. That takes care of the present and the future. What I *can't* do is go back in time and say, Hey -- I should have known that this thing was gonna be a business tool and so I should have tracked / archived / managed all my tweets from Thu Feb 01 05:03:16 + 2007. In my case, 3200 tweets goes back to some time in January of this year. So I'm missing about two years of history. I would like to petition Twitter to allow an authenticated user to retrieve *all* of his / her *own* tweets back as far as the Twitter database holds them. I don't particularly care about other peoples' tweets -- what I do with them is heavily biased towards *recent* activity. But I'd sure like to get my whole stream back as far as you have it. -- M. Edward (Ed) Borasky http://borasky-research.net/smart-at-znmeb I've never met a happy clam. In fact, most of them were pretty steamed.
[twitter-dev] Re: Should consumer token be kept secret?
Duane Roelands duane.roela...@gmail.com writes: No, there's really not a good solution for open source developers. :( If there really isn't a good solution for open source developers, there isn't a good solution for *any* developers unless you're running through a private proxy (and even that has problems). I think that the PIN solution is about as workable as anything at the present, and haven't seen any solid ideas for improving upon it without breaking the core principles of OAuth. As far as app reputation and source reporting goes, the OAuth solution is no less secure than basic auth source parameters (there's no verification that an application is authorized to use a given source parameter). -Michael -- mouse, n: A device for pointing at the xterm in which you want to type.
[twitter-dev] Re: Going all the way back -- the 3200-tweet limit is annoying / frustrating
I'm sure many people agree. Is there an existing Twitter API issue for it? If not, perhaps start one and let people vote on it as a feature? -damon -- http://twitter.com/damon On Sat, Jul 11, 2009 at 12:39 PM, M. Edward (Ed) Boraskyzzn...@gmail.com wrote: I've been talking with some of my Twitter friends in the Portland area and they / we are somewhat frustrated by the fact that we can only retrieve the most recent 3200 tweets via the API.
[twitter-dev] Re: Should consumer token be kept secret?
No, there's really not a good solution for open source developers. :( If there really isn't a good solution for open source developers, there isn't a good solution for *any* developers unless you're running through a private proxy (and even that has problems). I think that the PIN solution is about as workable as anything at the present, and haven't seen any solid ideas for improving upon it without breaking the core principles of OAuth. As far as app reputation and source reporting goes, the OAuth solution is no less secure than basic auth source parameters (there's no verification that an application is authorized to use a given source parameter). No less secure, but the problem I haven't seen an answer to is whether Twitter plans to use keys to lock out badly behaved applications. If that's true, then a rogue app can effectively DOS out an innocent unrelated app by masquerading as it and doing naughty things, and getting its key suspended. If they have no plans to do this, then I agree that it's no different than Basic Auth source parameters. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In memory of DeForest Kelley ---
[twitter-dev] Re: Streaming API -- New objects in markup stream. Test your code
John,
Any chance you can allow us to send an additional variable when we
connect and you guys send it in the new format? This would allow for
overlap and testing.
-Joel
On Jul 11, 2009, at 7:04 AM, John Kalucki jkalu...@gmail.com wrote:
Laurent,
There are examples of the new objects on the Streaming API wiki. The
XML and JSON formats are, sadly, not orthogonal. The objects aren't
flowing to give developers time to adjust. We'll probably enable this
in the middle of next week.
-John
On Jul 11, 12:34 am, Laurent Eschenauer laurent.eschena...@gmail.com
wrote:
Hi John,
I can't find such thing as a status or delete object in the JSON
feed.
There is indeed a status enveloppe in the XML, but the
corresponding
JSON object seems to be already one level deeper, only encapsulating
the data from the status itself.
Could you please clarify what we should be expecting to see in JSON ?
And maybe also provide some sample objects in the Wiki, both for XML
and JSON ?
Thanks !
-Laurent
On Jul 10, 8:00 pm, John Kalucki jkalu...@gmail.com wrote:
Note: The Streaming API is currently under a limited alpha test,
details below.
Please test that your Streaming API clients can handle unexpected
objects in the markup stream. Status deletion notice support is
being
added, but will be disabled until at least Thursday July 16th to
allow
developers a chance to check their code. From the
wiki,http://apiwiki.twitter.com/Streaming-API-Documentation:
Streams may also contain status deletion notices. Clients are
urged to
honor deletion requests and discard deleted statuses immediately.
* XML: deletestatusid1234/iduser_id3/user_id/
status/delete
* JSON: { delete: { status: { id: 1234, user_id: 3 } } }
Objects other than status and delete may be introduced into the
markup stream in a future release. Please ensure that your parser is
tolerant of unexpected objects.
Important Alpha Test Note:
The Streaming API (aka Hosebird) is currently under an alpha test.
All
developers using the Streaming API must tolerate possible
unannounced
and extended periods of unavailability, especially during off-hours,
Pacific Time. New features, resources and policies are being
deployed
on very little, if any, notice. Any developer may experiment with
the
unrestricted resources and provide feedback via this list. Access to
restricted resources is extremely limited and is only granted on a
case-by-case basis after acceptance of an additional terms of
service
document.
-John Kalucki
twitter.com/jkalucki
Services, Twitter Inc.
[twitter-dev] Re: User Search API
Is there a published road-map? Thanks. On Sat, Jul 11, 2009 at 6:53 AM, Doug Williams d...@twitter.com wrote: Samir, User search is something we would like to offer in the future through the API. The project is not highly ranking on the current overall roadmap, so there is no ship date to report. Thanks, Doug On Fri, Jul 10, 2009 at 2:53 PM, SamirR samir.ray...@gmail.com wrote: Are there plans to implement user search in the API (http:// twitter.com/search/users?q=)? Thanks! Samir -- Kevin Mesiab CEO, Mesiab Labs L.L.C. img src= http://twitterproforum.com/image.php?u=5type=sigpicdateline=1242113349; / 208-447-6016 http://www.mesiablabs.com http://www.plsadvise.com
[twitter-dev] Streaming API/ track method - results Tweets from Dec. 2008
Sorry, if I should know it. But is it usual that the results of the track method could be 6 months old? When I played with it I got tweets from Dec. 2008 or May or April or nearly realtime. Any way to get just the newest? Thanks Martin
[twitter-dev] Re: User Search API
There's a published roadmap for the next big iteration of the API (version 2) [1]. Your suggestion is already listed under Users and is assigned to ticket #357 [2]. 1. http://apiwiki.twitter.com/V2-Roadmap 2. http://code.google.com/p/twitter-api/issues/detail?id=357 -- Chris Thomson On 11-Jul-09, at 5:33 PM, Kevin Mesiab wrote: Is there a published road-map? Thanks. On Sat, Jul 11, 2009 at 6:53 AM, Doug Williams d...@twitter.com wrote: Samir, User search is something we would like to offer in the future through the API. The project is not highly ranking on the current overall roadmap, so there is no ship date to report. Thanks, Doug On Fri, Jul 10, 2009 at 2:53 PM, SamirR samir.ray...@gmail.com wrote: Are there plans to implement user search in the API (http:// twitter.com/search/users?q=)? Thanks! Samir -- Kevin Mesiab CEO, Mesiab Labs L.L.C. img src=http://twitterproforum.com/image.php?u=5type=sigpicdateline=1242113349 / 208-447-6016 http://www.mesiablabs.com http://www.plsadvise.com
[twitter-dev] Re: Should consumer token be kept secret?
It's different from basic auth in the way that oauth was primarily designed to be different -- the app need not know your password (thus preventing a rogue app from stealing it) and it need not send it over the wire with every request (thus preventing a rogue entity from monitoring and trapping it over the wire). On Sat, Jul 11, 2009 at 12:54, Cameron Kaiser spec...@floodgap.com wrote: No, there's really not a good solution for open source developers. :( If there really isn't a good solution for open source developers, there isn't a good solution for *any* developers unless you're running through a private proxy (and even that has problems). I think that the PIN solution is about as workable as anything at the present, and haven't seen any solid ideas for improving upon it without breaking the core principles of OAuth. As far as app reputation and source reporting goes, the OAuth solution is no less secure than basic auth source parameters (there's no verification that an application is authorized to use a given source parameter). No less secure, but the problem I haven't seen an answer to is whether Twitter plans to use keys to lock out badly behaved applications. If that's true, then a rogue app can effectively DOS out an innocent unrelated app by masquerading as it and doing naughty things, and getting its key suspended. If they have no plans to do this, then I agree that it's no different than Basic Auth source parameters. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In memory of DeForest Kelley --- -- Internets. Serious business.
[twitter-dev] Re: Streaming API/ track method - results Tweets from Dec. 2008
Unless there's been a server restart and some unusual resulting backlog, nearly all tweets from /track will be forwarded within a second or two of being posted. I suspect you are conflating the created_at of the user with the created_at of the status. I've done this many times. -John Kalucki twitter.com/jkalucki Services, Twitter Inc. On Jul 11, 2:37 pm, Germig i...@exbeerde.de wrote: Sorry, if I should know it. But is it usual that the results of the track method could be 6 months old? When I played with it I got tweets from Dec. 2008 or May or April or nearly realtime. Any way to get just the newest? Thanks Martin
[twitter-dev] Re: Streaming API -- New objects in markup stream. Test your code
We'll mail again and post on the @twitterapi account before we cry
havoc and let slip the hounds.
-John
On Jul 11, 2:26 pm, Joel Strellner j...@twitturly.com wrote:
John,
Any chance you can allow us to send an additional variable when we
connect and you guys send it in the new format? This would allow for
overlap and testing.
-Joel
On Jul 11, 2009, at 7:04 AM, John Kalucki jkalu...@gmail.com wrote:
Laurent,
There are examples of the new objects on the Streaming API wiki. The
XML and JSON formats are, sadly, not orthogonal. The objects aren't
flowing to give developers time to adjust. We'll probably enable this
in the middle of next week.
-John
On Jul 11, 12:34 am, Laurent Eschenauer laurent.eschena...@gmail.com
wrote:
Hi John,
I can't find such thing as a status or delete object in the JSON
feed.
There is indeed a status enveloppe in the XML, but the
corresponding
JSON object seems to be already one level deeper, only encapsulating
the data from the status itself.
Could you please clarify what we should be expecting to see in JSON ?
And maybe also provide some sample objects in the Wiki, both for XML
and JSON ?
Thanks !
-Laurent
On Jul 10, 8:00 pm, John Kalucki jkalu...@gmail.com wrote:
Note: The Streaming API is currently under a limited alpha test,
details below.
Please test that your Streaming API clients can handle unexpected
objects in the markup stream. Status deletion notice support is
being
added, but will be disabled until at least Thursday July 16th to
allow
developers a chance to check their code. From the
wiki,http://apiwiki.twitter.com/Streaming-API-Documentation:
Streams may also contain status deletion notices. Clients are
urged to
honor deletion requests and discard deleted statuses immediately.
* XML: deletestatusid1234/iduser_id3/user_id/
status/delete
* JSON: { delete: { status: { id: 1234, user_id: 3 } } }
Objects other than status and delete may be introduced into the
markup stream in a future release. Please ensure that your parser is
tolerant of unexpected objects.
Important Alpha Test Note:
The Streaming API (aka Hosebird) is currently under an alpha test.
All
developers using the Streaming API must tolerate possible
unannounced
and extended periods of unavailability, especially during off-hours,
Pacific Time. New features, resources and policies are being
deployed
on very little, if any, notice. Any developer may experiment with
the
unrestricted resources and provide feedback via this list. Access to
restricted resources is extremely limited and is only granted on a
case-by-case basis after acceptance of an additional terms of
service
document.
-John Kalucki
twitter.com/jkalucki
Services, Twitter Inc.
[twitter-dev] Re: Streaming API/ track method - results Tweets from Dec. 2008
Sorry, I should have seen it. You are right. Thanks a lot. Martin On 12 Jul., 03:25, John Kalucki jkalu...@gmail.com wrote: Unless there's been a server restart and some unusual resulting backlog, nearly all tweets from /track will be forwarded within a second or two of being posted. I suspect you are conflating the created_at of the user with the created_at of the status. I've done this many times. -John Kalucki twitter.com/jkalucki Services, Twitter Inc. On Jul 11, 2:37 pm, Germig i...@exbeerde.de wrote: Sorry, if I should know it. But is it usual that the results of the track method could be 6 months old? When I played with it I got tweets from Dec. 2008 or May or April or nearly realtime. Any way to get just the newest? Thanks Martin
[twitter-dev] API Curl: Status update result: http_code =0!
Hi there , I'm new to this group, so hello everyone, I'm tryng to set my first (php) use of the twitter API using CUrl and I'm experiencing a strange behaviour: I get this http_code zero when my post has been added and also when I can't authentificate. I read a previous post on this group saying it was caused by: curl_setopt($ch, CURLOPT_POST, 1); That post said that commenting out this line (or setting to false) would fix it. But if I do so I get a good 401 for password error which makes me happy but still have a 400: errorThis method requires a POST./error when it should post fine... I can't get my 200 even if the update is posted to my twitter succesfully using that curlopt_post. Any help greatly appreciated! thks
