[twitter-dev] Re: Update Profile Background using oauth
It does not seems to be OATH problem since user gets logged-in fine
but there is some issue while setting/uploading background..
If its OATH problem, it gave 'Invalid OATH signature Error'
On Nov 17, 6:16 am, jmathai jmat...@gmail.com wrote:
Which library are you using? Looking at this line:
$args = array('@image' = '@'.$temp_img);
it appears you might be using twitter-async.
On Nov 15, 9:51 pm, stevie stevie@gmail.com wrote:
Hi All,
Update profile background using twitter api is working fine
with username and password but on oauth its causing the problem and
returning the message
Something is technically wrong.
Thanks for noticing—we're going to fix it up and have things back to
normal soon.
I have tried passing the full image path(Absolute path) with @symbol
before but same problem exits!
$temp_img = 'D:/BackGroundPic/1.jpg';
$args = array('@image' = '@'.$temp_img); (or)
$args = array('image' = '@'.$temp_img);
But both results in unsuccessful.
Any Suggestions to overcome this issue will be helpful.
Thanks and regards,
Steve
[twitter-dev] retweets vs mentions
Hi all, I wondered if we already could start using the retweet API methods - for example statuses/retweet. Currently statuses/mentions also returns retweets , so what is the difference between thos and how should they be organized in an application implementing this functionality/ Thanks.
[twitter-dev] Re: retweets vs mentions
Mentions are anyone who replies or mentions or retweets you, retweets are exactly that, just retweets? On Nov 17, 10:15 am, twittme_mobi nlupa...@googlemail.com wrote: Hi all, I wondered if we already could start using the retweet API methods - for example statuses/retweet. Currently statuses/mentions also returns retweets , so what is the difference between thos and how should they be organized in an application implementing this functionality/ Thanks.
[twitter-dev] Re: Login issues
Still happening to me, and it only occurs when I login via my own server (87.117.224.42). I've started using oauth which works fine, but worried that other people using my site are also having issues. Thanks Ryan On Nov 17, 5:59 am, Mark McBride mmcbr...@twitter.com wrote: Is this still occurring? We saw a spike in odd authentication issues, but it appears to be a transient thing that sorted itself out. If this is still an issue I will investigate further. ---Mark On Sat, Nov 14, 2009 at 6:43 PM, Dewald Pretorius dpr...@gmail.com wrote: I am also getting complaints from users who cannot authenticate via the API with the same credentials that they use when logging on to twitter.com. Has the change, which limits invalid credentials lockout to a specific IP address, perhaps been accidentally rolled back? Dewald On Nov 14, 5:55 am, artesea ryancul...@gmail.com wrote: I'm still using HTTP requests to login via the API with a private dabr install I've got running. However I'm getting a large number of 401 - Could not authenticate you when I try to sign in. I recently changed my password on Twitter, however I have no problems login on the main site, viahttp://dabr.co.uk/andother still using HTTP. I see able to login with other usernames fine on my own install, and the 401 don't always appear. It's happening on every machine I use, and all the cookies have been wiped multiple times. Before I end up pulling my code apart, are they any issues with changed passwords and HTTP auth requests?
[twitter-dev] Re: Twitter API gives different results for different IPs?
Hello, we have built a little test page here: http://twavatars-dev.appspot.com/test?screen_name=freddyxyz And I'll head over to the code tracker now to post the URL and a comment. -H On Nov 16, 3:19 pm, Raffi Krikorian ra...@twitter.com wrote: Hi. This is a known issue and is being tracked on the google code tracker for the API - please feel free to add more information about this issue there. Thanks! On Nov 16, 2009, at 3:32 AM, Sarp Erdag sarp.er...@gmail.com wrote: Hello, I looks like the methods users/show and account/verify_credentials give different results especially for the profile_image_url block when called from different machines. After there is an avatar update (whether from the twitter web ui or over a 3rd party app that uses the api (oauth or basic) when these methods are called from different IPs, I see they are getting different profile_umage_urls. Sometimes the updated version is shown, sometimes not... Any recommendations / explanations how to deal with this issue?
[twitter-dev] Re: Streaming API with Dynamic Tag Set
Thanks thats great to know. I'm sure with this information some sort of new design that can be found. I'll be giving it some thought at the end of the week. Ben On Nov 16, 10:55 pm, John Kalucki jkalu...@gmail.com wrote: If you have a fairly stable set of tags, you should absolutely obtain those via the Streaming API. You can migrate dynamic queries that are made against the REST API to the Streaming API several times an hour. This will cut your Search velocity to everyone's benefit, and will improve your result set fidelity. Few tags generate more than a handful of updates per second, and most generate much less traffic. -John Benjamin Darfler wrote: It might not be the best use of the Search API but we have made a pretty successful system that polls for, on average a few hundred tags, in serial, at a rate that keeps us below the 20k/hr limit. We also respect 503 errors and back off accordingly. I think what might work the best is some sort of hybrid system. We are at a point where some tags/users are known a priori and need a quicker and more guaranteed delivery. We could set up a stream for that and keep the rest as search requests. I'll give the sampled stream some thought. Its possible that we could ingest the sampled stream and pull out messages that match one of our terms and dump the rest on the floor. I'd have to prototype that a bit to see if we end up with a satisfactory amount of messages. Its quite possible that setting up a stream with a few hundred tags would be an overwhelming and unnecessary amount of messages flowing into our system since we use twitter messages mostly as filler and don't require specific messages or even a lot of messages most of the time. Ben On Nov 16, 10:04 pm, John Kalucki jkalu...@gmail.com wrote: Benjamin, I don't think we have a good solution for this use case. Calling the Search REST API or the Streaming API aggressively aren't acceptable techniques. I'd suggest rethinking your app to be less demanding. Perhaps if you could compute your predicates in advance and keep your update rate to well below once per minute, you could be successful. Would it be possible to base some of your work off of a sampled stream? -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. Benjamin Darfler wrote: I have the use case where I want to ingest twitter messages based on a set of tags that will changes frequently (possibly a few times a min or more). I'm polling the search api and can vary the terms I'm searching for with each request. I would love to move over to the streaming api but I'm not sure if I can dynamically change the terms I'm filtering on without tearing down and restarting the stream which I imagine is not efficient nor particularly friendly to twitter. Is there a well defined way to use the stream api in this manner?
[twitter-dev] Re: retweets vs mentions
Mentions are any tweets that contain @yourscreenname in the tweet. Retweets are tweets that repeat a previously posted tweet (kind of like email forwarding). On Tue, Nov 17, 2009 at 7:08 AM, Rich rhyl...@gmail.com wrote: Mentions are anyone who replies or mentions or retweets you, retweets are exactly that, just retweets? On Nov 17, 10:15 am, twittme_mobi nlupa...@googlemail.com wrote: Hi all, I wondered if we already could start using the retweet API methods - for example statuses/retweet. Currently statuses/mentions also returns retweets , so what is the difference between thos and how should they be organized in an application implementing this functionality/ Thanks.
[twitter-dev] Re: Streaming API with Dynamic Tag Set
I re-read the section on updating filter predicates in the api doc and it seems to say that reconnecting every 2 min is acceptable. If thats the case that would have an impact on the design I'm kicking around. Ben On Nov 16, 10:55 pm, John Kalucki jkalu...@gmail.com wrote: If you have a fairly stable set of tags, you should absolutely obtain those via the Streaming API. You can migrate dynamic queries that are made against the REST API to the Streaming API several times an hour. This will cut your Search velocity to everyone's benefit, and will improve your result set fidelity. Few tags generate more than a handful of updates per second, and most generate much less traffic. -John Benjamin Darfler wrote: It might not be the best use of the Search API but we have made a pretty successful system that polls for, on average a few hundred tags, in serial, at a rate that keeps us below the 20k/hr limit. We also respect 503 errors and back off accordingly. I think what might work the best is some sort of hybrid system. We are at a point where some tags/users are known a priori and need a quicker and more guaranteed delivery. We could set up a stream for that and keep the rest as search requests. I'll give the sampled stream some thought. Its possible that we could ingest the sampled stream and pull out messages that match one of our terms and dump the rest on the floor. I'd have to prototype that a bit to see if we end up with a satisfactory amount of messages. Its quite possible that setting up a stream with a few hundred tags would be an overwhelming and unnecessary amount of messages flowing into our system since we use twitter messages mostly as filler and don't require specific messages or even a lot of messages most of the time. Ben On Nov 16, 10:04 pm, John Kalucki jkalu...@gmail.com wrote: Benjamin, I don't think we have a good solution for this use case. Calling the Search REST API or the Streaming API aggressively aren't acceptable techniques. I'd suggest rethinking your app to be less demanding. Perhaps if you could compute your predicates in advance and keep your update rate to well below once per minute, you could be successful. Would it be possible to base some of your work off of a sampled stream? -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. Benjamin Darfler wrote: I have the use case where I want to ingest twitter messages based on a set of tags that will changes frequently (possibly a few times a min or more). I'm polling the search api and can vary the terms I'm searching for with each request. I would love to move over to the streaming api but I'm not sure if I can dynamically change the terms I'm filtering on without tearing down and restarting the stream which I imagine is not efficient nor particularly friendly to twitter. Is there a well defined way to use the stream api in this manner?
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
I've been having this same issue when connecting to https://api.twitter.com. I would have thought that if it is a problem with my code, I would always get this error. However, it is intermittent. Most times it works, but a few times an hour I will get the error. Also, I never have this problem with https://twitter.com. On Nov 15, 6:46 pm, John Adams j...@twitter.com wrote: On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: Hi there, I'm doing some dev work and I'm getting occasional ssl errors when making calls against api.twitter.com/1. The most recent was posting to favorites/create. Is it possible some of the servers have bad certificates? Or is it likely I'm doing something very wrong? All of our servers have the same certificates; We have had some people report a similar issue before and we verified all of the certificates at that time. I do know of people having validation issues when they don't have current versions of OpenSSL, a current Root CA bundle, or their code has problems processing chained SSL certificates. Which program are you using to make requests against api.twitter.com? curl? Firefox? Twitter's SSL certs are issued by RapidSSL/Equifax. Make sure you have the proper root CA certs installed. If you're using OpenSSL libraries directly, remember that OpenSSL ships without any Root CA certs installed. Curl users will have similar problems as well -- you'll want to run mk- ca-bundle to get the proper ca-bundle installed. The TTYtter developers have a script that pulls the current CA bundle from Mozilla, here: http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt -john
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
Ops has been trying to track down this problem for a while. They confirmed that all servers have the correct cert. The current hypothesis is that there are some rogue servers that are being load balanced to that we don't expect to be accepting api.twitter.com traffic that do not have the correct cert. Sorry it's not fixed yet. We hope we can figure it out soon as it's a blocker for the transition of api traffic from twitter.com to api.twitter.com. On Tue, Nov 17, 2009 at 7:41 AM, Mageuzi mage...@gmail.com wrote: I've been having this same issue when connecting to https://api.twitter.com. I would have thought that if it is a problem with my code, I would always get this error. However, it is intermittent. Most times it works, but a few times an hour I will get the error. Also, I never have this problem with https://twitter.com. On Nov 15, 6:46 pm, John Adams j...@twitter.com wrote: On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: Hi there, I'm doing some dev work and I'm getting occasional ssl errors when making calls against api.twitter.com/1. The most recent was posting to favorites/create. Is it possible some of the servers have bad certificates? Or is it likely I'm doing something very wrong? All of our servers have the same certificates; We have had some people report a similar issue before and we verified all of the certificates at that time. I do know of people having validation issues when they don't have current versions of OpenSSL, a current Root CA bundle, or their code has problems processing chained SSL certificates. Which program are you using to make requests against api.twitter.com? curl? Firefox? Twitter's SSL certs are issued by RapidSSL/Equifax. Make sure you have the proper root CA certs installed. If you're using OpenSSL libraries directly, remember that OpenSSL ships without any Root CA certs installed. Curl users will have similar problems as well -- you'll want to run mk- ca-bundle to get the proper ca-bundle installed. The TTYtter developers have a script that pulls the current CA bundle from Mozilla, here: http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt -john -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
On Nov 17, 2009, at 10:50 AM, David Dellanave wrote: Could this be related to when an API request returns raw HTML like the over-loaded page? That would be my first guess. SSL/TLS negotiation happens much earlier in the transaction, so no, raw HTML is not a cause of this. -john
[twitter-dev] Retweets - where are they placed on timeline
Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim.
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
Hi Marcel, Thanks for following up on this. The bad cert responses I got were inconsistent. Often it would work fine, so what you've outlined here is one theory that would explain it. I think I'll switch back to twitter.com for this app, and look at using api.twitter.com in a future update. Tim. On Wed, Nov 18, 2009 at 7:46 AM, Marcel Molina mar...@twitter.com wrote: Ops has been trying to track down this problem for a while. They confirmed that all servers have the correct cert. The current hypothesis is that there are some rogue servers that are being load balanced to that we don't expect to be accepting api.twitter.com traffic that do not have the correct cert. Sorry it's not fixed yet. We hope we can figure it out soon as it's a blocker for the transition of api traffic from twitter.com to api.twitter.com. On Tue, Nov 17, 2009 at 7:41 AM, Mageuzi mage...@gmail.com wrote: I've been having this same issue when connecting to https://api.twitter.com. I would have thought that if it is a problem with my code, I would always get this error. However, it is intermittent. Most times it works, but a few times an hour I will get the error. Also, I never have this problem with https://twitter.com. On Nov 15, 6:46 pm, John Adams j...@twitter.com wrote: On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: Hi there, I'm doing some dev work and I'm getting occasional ssl errors when making calls against api.twitter.com/1. The most recent was posting to favorites/create. Is it possible some of the servers have bad certificates? Or is it likely I'm doing something very wrong? All of our servers have the same certificates; We have had some people report a similar issue before and we verified all of the certificates at that time. I do know of people having validation issues when they don't have current versions of OpenSSL, a current Root CA bundle, or their code has problems processing chained SSL certificates. Which program are you using to make requests against api.twitter.com? curl? Firefox? Twitter's SSL certs are issued by RapidSSL/Equifax. Make sure you have the proper root CA certs installed. If you're using OpenSSL libraries directly, remember that OpenSSL ships without any Root CA certs installed. Curl users will have similar problems as well -- you'll want to run mk- ca-bundle to get the proper ca-bundle installed. The TTYtter developers have a script that pulls the current CA bundle from Mozilla, here: http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt -john -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Retweets - where are they placed on timeline
Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Retweets - where are they placed on timeline
Marcel, This collapsing behavior is far from ideal and will cause people with busy timelines to completely miss retweets. Nobody is online 24x7, and if only the first retweet of an update is shown in a user's timeline, they will miss completely it if the first retweet happened several hours before they login and check their timeline. In other words, someone can retweet the same update while they are online and they still won't see it. From a Twitter-internal technical standpoint, new retweets are ideal because it eliminates a lot of duplication and accompanying processing and storage requirements. From a user's perspective, it is far from ideal. With old-style retweets, if I saw ten retweets of the same thing, I knew to check it out because obviously a lot of people felt it was something worth sharing with their followers. With the new retweets, I'm going to miss that completely. Even if I notice the first retweet, the retweeted by section may show only one or two people, and I won't know that the update was retweeted by twenty more people after I happened to look at it. In my irrelevant opinion, the new retweet feature is trying to fix something that was not broken. Dewald On Nov 17, 3:58 pm, Marcel Molina mar...@twitter.com wrote: Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
Re: [twitter-dev] Re: Retweets - where are they placed on timeline
Hey Dewald, What if your twitter client had a feature of showing you tweets in your timeline that had been retweeted by 10 or more people? That's possible now. It was very very difficult before. Marcel, thanks for your reply earlier. I noticed something yesterday that indicated this 'probably' wasn't happening. (RT by NZKoz, which he's since deleted). I'll do more testing today, and likely find what was wrong with my testing yesterday. :-) Tim. On Wed, Nov 18, 2009 at 9:37 AM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, This collapsing behavior is far from ideal and will cause people with busy timelines to completely miss retweets. Nobody is online 24x7, and if only the first retweet of an update is shown in a user's timeline, they will miss completely it if the first retweet happened several hours before they login and check their timeline. In other words, someone can retweet the same update while they are online and they still won't see it. From a Twitter-internal technical standpoint, new retweets are ideal because it eliminates a lot of duplication and accompanying processing and storage requirements. From a user's perspective, it is far from ideal. With old-style retweets, if I saw ten retweets of the same thing, I knew to check it out because obviously a lot of people felt it was something worth sharing with their followers. With the new retweets, I'm going to miss that completely. Even if I notice the first retweet, the retweeted by section may show only one or two people, and I won't know that the update was retweeted by twenty more people after I happened to look at it. In my irrelevant opinion, the new retweet feature is trying to fix something that was not broken. Dewald On Nov 17, 3:58 pm, Marcel Molina mar...@twitter.com wrote: Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Retweets - where are they placed on timeline
Does everyone have access to the ReTweet beta now? If not when is expected deployment. I have a fully working ReTweet API implementation but I don't want to submit it to Apple until everyone has access to it. On Nov 17, 9:19 pm, Marcel Molina mar...@twitter.com wrote: As Tim mentioned, clients are empowered to uncollapse retweets if they'd like. On Tue, Nov 17, 2009 at 12:37 PM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, This collapsing behavior is far from ideal and will cause people with busy timelines to completely miss retweets. Nobody is online 24x7, and if only the first retweet of an update is shown in a user's timeline, they will miss completely it if the first retweet happened several hours before they login and check their timeline. In other words, someone can retweet the same update while they are online and they still won't see it. From a Twitter-internal technical standpoint, new retweets are ideal because it eliminates a lot of duplication and accompanying processing and storage requirements. From a user's perspective, it is far from ideal. With old-style retweets, if I saw ten retweets of the same thing, I knew to check it out because obviously a lot of people felt it was something worth sharing with their followers. With the new retweets, I'm going to miss that completely. Even if I notice the first retweet, the retweeted by section may show only one or two people, and I won't know that the update was retweeted by twenty more people after I happened to look at it. In my irrelevant opinion, the new retweet feature is trying to fix something that was not broken. Dewald On Nov 17, 3:58 pm, Marcel Molina mar...@twitter.com wrote: Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
Re: [twitter-dev] Re: Retweets - where are they placed on timeline
The retweet feature is currently rolled out to 50% of users. We gradually ramping it up. Full availability should be soon unless issues arise as we incrementally roll it out. Thanks for your patience. It's awesome to have people ready to pull the trigger on retweet. On Tue, Nov 17, 2009 at 1:27 PM, Rich rhyl...@gmail.com wrote: Does everyone have access to the ReTweet beta now? If not when is expected deployment. I have a fully working ReTweet API implementation but I don't want to submit it to Apple until everyone has access to it. On Nov 17, 9:19 pm, Marcel Molina mar...@twitter.com wrote: As Tim mentioned, clients are empowered to uncollapse retweets if they'd like. On Tue, Nov 17, 2009 at 12:37 PM, Dewald Pretorius dpr...@gmail.com wrote: Marcel, This collapsing behavior is far from ideal and will cause people with busy timelines to completely miss retweets. Nobody is online 24x7, and if only the first retweet of an update is shown in a user's timeline, they will miss completely it if the first retweet happened several hours before they login and check their timeline. In other words, someone can retweet the same update while they are online and they still won't see it. From a Twitter-internal technical standpoint, new retweets are ideal because it eliminates a lot of duplication and accompanying processing and storage requirements. From a user's perspective, it is far from ideal. With old-style retweets, if I saw ten retweets of the same thing, I knew to check it out because obviously a lot of people felt it was something worth sharing with their followers. With the new retweets, I'm going to miss that completely. Even if I notice the first retweet, the retweeted by section may show only one or two people, and I won't know that the update was retweeted by twenty more people after I happened to look at it. In my irrelevant opinion, the new retweet feature is trying to fix something that was not broken. Dewald On Nov 17, 3:58 pm, Marcel Molina mar...@twitter.com wrote: Should appear as a new tweet with the time of the retweet, not the original tweet creation time. That assumes though that no one else has retweeted it to you yet. If someone else has then this additional retweet won't appear in your timelines except for the statuses/retweets/id resource that lists up to 100 retweets for a given tweet. Duplicates are collapsed out of the other timelines. On Tue, Nov 17, 2009 at 11:46 AM, Tim Haines tmhai...@gmail.com wrote: Hi guys, I'm wondering if anyone can clarify. The services I run often shown tweets that are several months old, and offer the RT button next to them. If someone clicks to RT the tweet, how does the tweet get presented to people that aren't following the original tweeter? Is it placed at the top of the timeline appearing as a new tweet, or is it placed at the time the original tweet was tweeted? i.e. months ago, so likely to never be seen? If it would be placed months ago, it makes RT pointless for older tweets, in which case I'll switch to 'classic mode' RT's. Tim. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] api.twitter.com SSL issue should be resolved now
After doing some righteous spelunking our ops team discovered a small misconfiguration that was very likely the culprit of the intermittent untrusted cert error people were getting when trying to hit api.twitter.com over SSL. This should be all fixed now. To those who reported the problem thank you. Please let us know if you still run into it. We don't think you will be we want to make sure it's totally fixed. Thanks to everyone who's been patient as we ferreted out this subtle problem. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Issue while implementing Twitter's OAuth
Hi All, Am new to twitter and wants to create an application in twitter for sharing information from my site. For this I have downloaded an PHP library for working with Twitter's OAuth API from the below link http://github.com/abraham/twitteroauth with the help specified in the link https://docs.google.com/View?docID=dcf2dzzs_2339fzbfsf4 To achieve Twitter's OAuth I followed the exact steps which are specified in https://docs.google.com/View?docID=dcf2dzzs_2339fzbfsf4 but I'm getting error as shown below Fatal error: Cannot unset string offsets in D:\xampp\htdocs\civio \twitter\twitteroauth2.0\twitteroauth\twitteroauth.php on line 145 I commented the line where I got the above line and I still get the error Warning: array_merge() [function.array-merge]: Argument #2 is not an array in D:\xampp\htdocs\civio\twitter\twitteroauth2.0\twitteroauth \OAuth.php on line 249 and nothing is happing after this. Am total stuck here. Please help me in resolving this issue. Thanks in advance, Venkatesh M.
[twitter-dev] Return Posts in_reply_to
Are there any plans to add an API call to return all posts that are in_reply_to a specific post? I'm constantly coming across tweets that are questions directed at specific users and I have no easy way of finding whether that user responded or not short of searching their timeline around the approximate time. We could make great use of this on Tweetree if it were implemented. Thanks! John Fredrickson Draconis Software http://twitter.com/jfredson
[twitter-dev] Missing Search API Results
Hi All, We have been noticing gaps appearing in search results at times when doing geocoded searches in particular. For example with this search over South Eastern Australia : http://search.twitter.com/search.json?rpp=100lang=enpage=1geocode=-35.2,144.0,1000km Occasionally produces results with large gaps in the created_at for the tweets. For example, I just got these created_at for tweets returned : ... Tue, 17 Nov 2009 22:59:50 + Tue, 17 Nov 2009 22:59:49 + Tue, 17 Nov 2009 22:59:48 + Tue, 17 Nov 2009 22:59:43 + Tue, 17 Nov 2009 22:52:04 + Tue, 17 Nov 2009 22:52:04 + Tue, 17 Nov 2009 22:51:34 + Tue, 17 Nov 2009 22:50:21 + Tue, 17 Nov 2009 22:50:20 + Tue, 17 Nov 2009 22:43:37 + ... This area is producing multiple tweets per second, but there are some gaps there many minutes long. A subsequent search 10's of seconds, to a few minutes later 'fills in these gaps' with many many more tweets from the periods in between these minutes-long gaps, confirming that the initial search was in fact sparse. The same effect exists via the normal web search interface also. It has previously been possible to just use the maximum id of the tweets from the previous search result set, and then only page through results until you saw that id again. But having the search results appear out of order means this method is not possible. It means you would have to search across all 15 pages x 100 rpp continuously in order to ensure something approaching a complete result set. Even then it will not always be possible if ~ 1500 of results 'appear at once'. This is not sustainable for both the app doing the searching, or from the point of view of the many additional requests that would have to hit Twitter's servers. Is this a problem to be resolved, or moving forward are we going to continue to get results appearing via search out of order from their creation date like this? Thanks, JB.
[twitter-dev] new search function added blazingstreams.com
hi, I've added search to blazingstreams.com in order to find news from our database of real time news (curated, filtered, ranked and classified by category/topics in near real time). If somebody is interested in using search for a 3rd party, please let me know, I will be happy to expose an API for that matter. Best eche...@yahoo.com www.blazingstreams.com
[twitter-dev] Please provide a more specific query error from Twitter API
Hai, I have send a request to Twitter API for the tweets by using request URL including Geo Code with location *US* and radius 2400 KM then i got error *Please provide a more specific query* , if i decreased radius from 2400KM then i got tweets at a particular radius but some times it worked at 2400 KM radius also. Please any one tell me the solution for this. Regards Praveen
