[twitter-dev] Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff
On the callback page im trying to figure out a way to differenciate when a user logged in but already has an access token before requesting another one. Most of the methods use the verifycredentials method to make sure you have access to, but you dont know what the user's name is before you call that and you need the access token to do so. Login through twitter - callback app (since they just logged in and didnt allow the app i must already have the access token in the db) Login through twitter - allow access since he/she is registering to a new app - retrieve access store and login since they did not have an access token before. Or on login just rerequest the access token and restore it, which isnt a problem, just seems that there may be a different way to do it.
[twitter-dev] Re: Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff
If you already have an access token for that user, then you don't need to send them to the authorization page. You cannot get the username and password they just put into the authorization page. If you want the username that they entered into the authorization page, when you request the access token, the username is returned as one of the Http headers. On Oct 23, 2009, at 5:33 AM, shawninreach shawninre...@gmail.com wrote: On the callback page im trying to figure out a way to differenciate when a user logged in but already has an access token before requesting another one. Most of the methods use the verifycredentials method to make sure you have access to, but you dont know what the user's name is before you call that and you need the access token to do so. Login through twitter - callback app (since they just logged in and didnt allow the app i must already have the access token in the db) Login through twitter - allow access since he/she is registering to a new app - retrieve access store and login since they did not have an access token before. Or on login just rerequest the access token and restore it, which isnt a problem, just seems that there may be a different way to do it.
[twitter-dev] Same list on firther pagination
Hi, I use pagination (using cursor) for getting followers list. But when I provide the value of cursor on second try, only the first list is again returned. Please help. Thanks, Pradeep
[twitter-dev] Re: Welcome the the Twitter Development Talk
Hey can you help? I want the list of following of a specific user using php. Kindly revert solution if you know it. On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti da...@davebsoft.comwrote: I meant to send that to list owner. Sorry. -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF
[twitter-dev] Re: What to do with the access token after you've received it
Interesting tho, Twitter is putting a lot of trust in the third-party app that they won't mismange tokens. At least it's better than basic auth. Thanks again. I don't think so. It's the _user_ who's asked if he trusts that third party app to not mismanage tokens. Twitter's got nothing to do with it, if you think about it. Tino
[twitter-dev] Re: updateStatus API
Read: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0update Annotation für in_reply_to_status_id: Note: This parameter will be ignored unless the author of the tweet this parameter references is mentioned within the status text. Therefore, you must include @username, where username is the author of the referenced tweet, within the update. Hope this helps. Tino On Oct 23, 3:40 am, Guru mp.gurucha...@gmail.com wrote: Hi, To reply for a tweet, I used twitter.updateStatus (status,inreplyStatusId) api. Reply posted successfully to twitter but it shows only about 2 minutes ago from Twitter 4j and it does not show in reply to 'original tweet'. Am I using the right api or Is there any api to show a link to original tweet? Thanks, Guru
[twitter-dev] Re: from:user and since_id breaking Search API
We are experiencing the same thing as Marc. We are not using from: though. But intermittently it gets tweets in significant number. If I try to get the same set again using the since_id for this particular crawl, I again get no tweets. Any Idea on this issue? Thanks. On Oct 23, 10:48 am, Marc W marcwanchipm...@gmail.com wrote: We've started seeing this too. If we specify a since_id, then periodic refetches will frequently return no new tweets (but sometimes they will return new ones). If we simply drop the since_id, then all new tweets are fetched. Some new server optimization thing gone wrong? Thanks! On Oct 20, 10:06 pm, Christopher Warren christopher.war...@gmail.com wrote: We have an app that runssearchesregularly, and recently stopped receiving newtweets. After investigating we found a search combination that seems to break the search API. Instead of getting a response withnotweets, an .atom request errors and a .json request 404s. http://search.twitter.com/search.json?q=from:silent_tester02since_id.. Changing the query to not use from:username works as expect, but I've put several usernames in and they all respond the same way. I haven't managed to narrow down the cause of the problem much further than that, but we're handling it in our code by rescuing any failedsearchesand appending since: with the date of the most recent tweet to the q. Any thoughts on what might be causing this would be appreciated.
[twitter-dev] Re: cursor based paging
John, Please not that the API documentation on this link http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0followers tells the users to use negated values on each subsequent requests. Please take immediate steps to correct this in the documentation. Regards, Pradeep On Oct 16, 10:57 am, John Kalucki jkalu...@gmail.com wrote: You are negating the values on subsequent requests. Start with -1 (negative 1). Then, just use thecursorvalue exactly as returned. Everywhichway, it works just fine. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 15, 2:11 pm, dozykraut bernhard.schul...@gmx.net wrote: http:// twitter.com/statuses/followers/username.xml?cursor=-1 gives me page 1 of my followers list,. When I then request http:// twitter.com/ statuses/followers/username.xml?cursor=-new_cursor_value I get page 1 again. The same happens when I requesthttp://twitter.com/statuses/followers.xml?screen_name=usernamecursor... So everywhichway - it don't work
[twitter-dev] Re: cursor based paging
Fixed. On Oct 23, 1:02 am, Pradeep pradeep.de...@gmail.com wrote: John, Please not that the API documentation on this linkhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f... tells the users to use negated values on each subsequent requests. Please take immediate steps to correct this in the documentation. Regards, Pradeep On Oct 16, 10:57 am, John Kalucki jkalu...@gmail.com wrote: You are negating the values on subsequent requests. Start with -1 (negative 1). Then, just use thecursorvalue exactly as returned. Everywhichway, it works just fine. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 15, 2:11 pm, dozykraut bernhard.schul...@gmx.net wrote: http:// twitter.com/statuses/followers/username.xml?cursor=-1 gives me page 1 of my followers list,. When I then request http:// twitter.com/ statuses/followers/username.xml?cursor=-new_cursor_value I get page 1 again. The same happens when I requesthttp://twitter.com/statuses/followers.xml?screen_name=usernamecursor... So everywhichway - it don't work
[twitter-dev] Re: updateStatus API
Thanks Tino .. It helped, now I am getting the required link. ~ Guru On Oct 23, 4:28 am, ElPlatero t...@wi-05.de wrote: Read:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0u... Annotation für in_reply_to_status_id: Note: This parameter will be ignored unless the author of the tweet this parameter references is mentioned within the status text. Therefore, you must include @username, where username is the author of the referenced tweet, within the update. Hope this helps. Tino On Oct 23, 3:40 am, Guru mp.gurucha...@gmail.com wrote: Hi, To reply for a tweet, I used twitter.updateStatus (status,inreplyStatusId) api. Reply posted successfully to twitter but it shows only about 2 minutes ago from Twitter 4j and it does not show in reply to 'original tweet'. Am I using the right api or Is there any api to show a link to original tweet? Thanks, Guru
[twitter-dev] Re: from:user and since_id breaking Search API
Christopher To my recollection, for search with since_id to work properly, the tweet id must be in the search index. In this case: http://search.twitter.com/search?q=+from%3Asilent_tester02 does not yield the Dinner, movie, drinks. tweet in the index. As an aside, I did an exact match search on that phrase above and it returned many results that are not exact matches. But that's a separate issue. You could file an issue about the fact that the results coming back are not always consistent, but the first thing I would do is make sure that I am using a since_id that actually exists in the search index. Granted this can be a bit of a pain to verify this 100% of the time because sometimes tweets do not end up in the search index (which appears to be the case here). But in my experience, most of the time, they do. So as a test, pick a tweet you know is in the index and make some calls with it over a period of time. See if the results are consistent. Best, -damon -- http://twitter.com/damon On Tue, Oct 20, 2009 at 9:06 AM, Christopher Warren christopher.war...@gmail.com wrote: We have an app that runs searches regularly, and recently stopped receiving new tweets. After investigating we found a search combination that seems to break the search API. Instead of getting a response with no tweets, an .atom request errors and a .json request 404s. http://search.twitter.com/search.json?q=from:silent_tester02since_id=4979161317 http://search.twitter.com/search.atom?q=from:silent_tester02since_id=4979161317 Changing the query to not use from:username works as expect, but I've put several usernames in and they all respond the same way. I haven't managed to narrow down the cause of the problem much further than that, but we're handling it in our code by rescuing any failed searches and appending since: with the date of the most recent tweet to the q. Any thoughts on what might be causing this would be appreciated.
[twitter-dev] Re: from:user and since_id breaking Search API
I'm getting the same issue as Marc and harshavs too. I'm using since_id to start a search from the last set of resuts but generally get 0 results most of the time, even though the same search without since_id yields lots of results. I could start logging tweet IDs against user IDs, and then work backwards down the list of past results until I get a since_id that yields results, but it does seem like a bit of a pain. This is my first time using the search API so I can't even tell you when this started happening. It just happens! For info: search is using negation operators, OR and from: Dave On Oct 23, 10:29 am, harshavs harsh...@gmail.com wrote: We are experiencing the same thing as Marc. We are not using from: though. But intermittently it gets tweets in significant number. If I try to get the same set again using the since_id for this particular crawl, I again get no tweets. Any Idea on this issue? Thanks. On Oct 23, 10:48 am, Marc W marcwanchipm...@gmail.com wrote: We've started seeing this too. If we specify a since_id, then periodic refetches will frequently return no new tweets (but sometimes they will return new ones). If we simply drop the since_id, then all new tweets are fetched. Some new server optimization thing gone wrong? Thanks! On Oct 20, 10:06 pm, Christopher Warren christopher.war...@gmail.com wrote: We have an app that runssearchesregularly, and recently stopped receiving newtweets. After investigating we found a search combination that seems to break the search API. Instead of getting a response withnotweets, an .atom request errors and a .json request 404s. http://search.twitter.com/search.json?q=from:silent_tester02since_id.. Changing the query to not use from:username works as expect, but I've put several usernames in and they all respond the same way. I haven't managed to narrow down the cause of the problem much further than that, but we're handling it in our code by rescuing any failedsearchesand appending since: with the date of the most recent tweet to the q. Any thoughts on what might be causing this would be appreciated.
[twitter-dev] Geolocation API Status?
Any updates on the the release of the Geolocation Platform and API? I have a few things in the hopper I would like to test. Thanks, AL
[twitter-dev] lang parameter in the search api
The language filter in the search api doesnt seem very accurate. I've noticed that using Google Translate API for lang detection allow to refine results very well. So I suggest, if Twitter makes a deal with google, try to get their lang detection system :) It could be great for stream api too...
[twitter-dev] Re: Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff
Ok cool thanks. So is there any method to see what user was authorized to get to the callback url before rerequesting an access token. Im using twitter's login to be a single sign on for my site so thats why im directing them to the authorization page still. I wanted to be able to check if i had the access token in the db before requesting a new one just because it seems cleaner, but the only method is just rerequesting it seems atm. Thanks. On Oct 23, 6:13 am, ryan alford ryanalford...@gmail.com wrote: If you already have an access token for that user, then you don't need to send them to the authorization page. You cannot get the username and password they just put into the authorization page. If you want the username that they entered into the authorization page, when you request the access token, the username is returned as one of the Http headers. On Oct 23, 2009, at 5:33 AM, shawninreach shawninre...@gmail.com wrote: On the callback page im trying to figure out a way to differenciate when a user logged in but already has an access token before requesting another one. Most of the methods use the verifycredentials method to make sure you have access to, but you dont know what the user's name is before you call that and you need the access token to do so. Login through twitter - callback app (since they just logged in and didnt allow the app i must already have the access token in the db) Login through twitter - allow access since he/she is registering to a new app - retrieve access store and login since they did not have an access token before. Or on login just rerequest the access token and restore it, which isnt a problem, just seems that there may be a different way to do it.
[twitter-dev] Re: Welcome the the Twitter Development Talk
I love lamp. (or as we say in my office, i love linq)
[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?
Seriously. I'm no Flash developer, but I know more than a few Flash/ Flex developers just dying to get some pretty impressive apps out there. Right now, they're pretty much hamstrung by this limitation. On Oct 21, 1:31 pm, orian orianm...@gmail.com wrote: Now that api.twitter.com has gone live, can we please have a less restrictive crossdomain.xml so that Flash apps can access the API without requiring the use of a proxy? This was being planned more than a year and a half ago:http://groups.google.com/group/twitter-development-talk/browse_thread...
[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?
+1 ! This could really enable some awesome web clients for Twitter. On Oct 21, 1:31 pm, orian orianm...@gmail.com wrote: Now that api.twitter.com has gone live, can we please have a less restrictive crossdomain.xml so that Flash apps can access the API without requiring the use of a proxy? This was being planned more than a year and a half ago:http://groups.google.com/group/twitter-development-talk/browse_thread...
[twitter-dev] Re: New behaviour for statuses/update API call for 141+ char sized messages and duplicates?
Hi, I'm seeing the same thing that Ole is. Twitter is not truncating the status, but rather returning the last correctly updated status. -- Kevin On Oct 16, 4:58 am, janole s...@mobileways.de wrote: According to my tests, messages will not be truncated anymore! Instead, you will get the most recentstatusupdateas a reply. Is this a bug or feature? Also, it seems as if the API now checks for duplicates in your backlog of statuses and not just you most recent tweet. Previously, only the last tweet was checked: - Last tweet test - Send new tweet with status=test will return the oldstatus(with the old status_id) but if you had something like this: Last tweet Hello, world. Second last tweet test Then you were able to create a new tweet with status=test! This is not possible at the moment. Bug or feature? I'm getting a lot of complaints from my Twitter client users who apparently experience both of these new behaviours or bugs (long tweets fail, duplicates fail.) Ole @ mobileways.de On Twitter:http://twitter.com/janole On Oct 15, 8:26 pm, Josh Roesslein jroessl...@gmail.com wrote: If you send a message longer than 140 twitter will truncate it and set the truncate value on thestatusto True. For duplicates it will just ignore thestatus. Josh On Thu, Oct 15, 2009 at 1:20 PM, janole s...@mobileways.de wrote: Hi, I just figured out that when calling statuses/updatewith a text longer than 140 chars, the reply of that API call will be 200 OK with the laststatusof the user. Wouldn't it be better to return some sort of error message? The same seems to be happening when sending a duplicate tweet. Ole -- Jan Ole Suhr s...@mobileways.de On Twitter:http://twitter.com/janole
[twitter-dev] Re: Welcome the the Twitter Development Talk
My requirement is to get Following list not Follower list. On Fri, Oct 23, 2009 at 9:33 PM, ryan alford ryanalford...@gmail.comwrote: http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers idshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-followers%C2%A0ids On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha gauravshah...@gmail.comwrote: Hey can you help? I want the list of following of a specific user using php. Kindly revert solution if you know it. On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti da...@davebsoft.comwrote: I meant to send that to list owner. Sorry. -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF
[twitter-dev] OAuth without user interaction
In development of a twitter app, we are using unique twitter account to post updates in twitter. User and password its in config files server side. We need post tweets with from appname modified and not just API like now happens. With a little research we know source=appname param its deprecated, or still some way to work with this in new apps? In other hand, ¿we can use Oauth without user interaction? ¿Some experience about this?
[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?
Is this planned already? Please do something about this, using a proxy is a sloppy way of just communicating with the API directly. -Pete On Oct 21, 1:31 pm, orian orianm...@gmail.com wrote: Now that api.twitter.com has gone live, can we please have a less restrictive crossdomain.xml so that Flash apps can access the API without requiring the use of a proxy? This was being planned more than a year and a half ago:http://groups.google.com/group/twitter-development-talk/browse_thread...
[twitter-dev] Re: OAuth without user interaction
It is possible to do OAuth without user interaction if you have their username and password, but this is frowned upon by Twitter and could get your IP blacklisted. OAuth is the only way to get the source to be your app. Ryan On Fri, Oct 23, 2009 at 2:22 PM, Marcos just...@gmail.com wrote: In development of a twitter app, we are using unique twitter account to post updates in twitter. User and password its in config files server side. We need post tweets with from appname modified and not just API like now happens. With a little research we know source=appname param its deprecated, or still some way to work with this in new apps? In other hand, ¿we can use Oauth without user interaction? ¿Some experience about this?
[twitter-dev] Re: Welcome the the Twitter Development Talk
Let's not do any looking for ourselves. http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends idshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-friends%C2%A0ids http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends%C2%A0idsJust incase you have any questions about API methods, you should probably check out the API wiki first since it lists ALL API methods and gives a description of what they actually do. http://apiwiki.twitter.com/Twitter-API-Documentation On Fri, Oct 23, 2009 at 12:38 PM, Gaurav Shaha gauravshah...@gmail.comwrote: My requirement is to get Following list not Follower list. On Fri, Oct 23, 2009 at 9:33 PM, ryan alford ryanalford...@gmail.comwrote: http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers idshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-followers%C2%A0ids On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha gauravshah...@gmail.comwrote: Hey can you help? I want the list of following of a specific user using php. Kindly revert solution if you know it. On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti da...@davebsoft.comwrote: I meant to send that to list owner. Sorry. -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF
[twitter-dev] Re: Welcome the the Twitter Development Talk
You could also use this http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses friendshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses%C2%A0friends http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses%C2%A0friendsif you wanted to get the latest status of the friends. On Fri, Oct 23, 2009 at 4:34 PM, ryan alford ryanalford...@gmail.comwrote: Let's not do any looking for ourselves. http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends idshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-friends%C2%A0ids http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends%C2%A0idsJust incase you have any questions about API methods, you should probably check out the API wiki first since it lists ALL API methods and gives a description of what they actually do. http://apiwiki.twitter.com/Twitter-API-Documentation On Fri, Oct 23, 2009 at 12:38 PM, Gaurav Shaha gauravshah...@gmail.comwrote: My requirement is to get Following list not Follower list. On Fri, Oct 23, 2009 at 9:33 PM, ryan alford ryanalford...@gmail.comwrote: http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers idshttp://apiwiki.twitter.com/Twitter-REST-API-Method:-followers%C2%A0ids On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha gauravshah...@gmail.comwrote: Hey can you help? I want the list of following of a specific user using php. Kindly revert solution if you know it. On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti da...@davebsoft.comwrote: I meant to send that to list owner. Sorry. -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF -- Warm Regards, Gaurav Shaha 9823359549. All Persons have weakness.. But each will have one particular Strength.. That will overwrite all weakness, if u believe in URSELF
[twitter-dev] Re: API Proposal : Bulk fetch of user details
I'm completely on board with any strategy that will simplify (or especially amplify) the amount of graph data I can get. I had a discussion recently with Ryan where he indicated an openness to ideas of this sort because there is (he says) no getting around the 20K rate limits... an idea I find preposterous, but OK... whatever! So I'll be very interested to see if we can gain any traction on this front. I definitely can't get the amount of data I need to keep my app reasonably fresh with the rate limits available. - Waldron GraphEdge.com On Oct 22, 2:52 pm, Harshad RJ harshad...@gmail.com wrote: Hi, I am collating the thoughts in this thread [1] into a proposal to improve the efficiency of social-graphing applications. A common API access pattern for social-graphing applications seems to be: 1. Get the friend/follower ids of a user with [*friends/ids*] or [* followers/ids*] 2. Get user details one at a time with [*users/show*] (This approach saves on bandwidth by not using the [*statuses/friends*] method, as that would return redundant info when traversing a network) Now, since [*users/show*] is not a paginated API, it is easily possible to save bandwidth and connection overhead by clubbing multiple requests in one call. For a social-graphing application, the amount of user information needed is minimal. For example, the following amount of information would be sufficient for my application [1]: ?xml version=1.0 encoding=UTF-8? user id1401881/id screen_namedougw/screen_name followers_count1031/followers_count friends_count293/friends_count created_atSun Mar 18 06:42:26 + 2007/created_at statuses_count3390/statuses_count status created_atTue Apr 07 22:52:51 + 2009/created_at /status /user This is significantly smaller than the data returned by [*users/show*]. To prevent misuse of the new API the following could be enforced: 1. A maximum limit on number of users that can be queried in one request 2. Rate limiting based on number of users requested. For example, if (N) users' details were requested in one call, count it as (N/2) requests. This will provide incentive for using the new API as well as dettering misuse. [1]http://groups.google.com/group/twitter-development-talk/browse_thread... [2]http://twinkler.in cheers, -- Harshad RJhttp://hrj.wikidot.com
[twitter-dev] Re: OAuth without user interaction
On Fri, 23 Oct 2009 16:32:25 -0400 ryan alford ryanalford...@gmail.com wrote: It is possible to do OAuth without user interaction if you have their username and password, but this is frowned upon by Twitter and could get your IP blacklisted. You do need user interaction to get initial approval for a token, after which you can reuse a token until it is revoked. There is a chance (Has this happened recently?) that a token may expire without obvious reason, but they are supposed to be reusable. There's no replacement for testing, which has been absent in my shop recently because of the churn on the API... which I'm hoping will be addressed by versioning. Chris Babcock
[twitter-dev] Re: API 140 character truncation change?
I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen knig...@gmail.com wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868 http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e# It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman d...@fishtwits.com wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line Bug? Updates 140 characters return success with prior update payload. See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded no duplicates policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a 200 OK status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the 200 OK response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.org http://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius dpr...@gmail.com wrote: You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen cano...@gmail.com wrote: I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen knig...@gmail.com wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread. .. http://groups.google.com/group/twitter-development-talk/browse_thread. .. It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman d...@fishtwits.com wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line Bug? Updates 140 characters return success with prior update payload. See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded no duplicates policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a 200 OK status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the 200 OK response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.org http://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
Instead of all of us having to do fancy tap-dances, the proper solution is for Twitter to issue an error response when a sent tweet is rejected for whatever reason. Dewald On Oct 23, 7:58 pm, AJ Chen cano...@gmail.com wrote: then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius dpr...@gmail.com wrote: You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen cano...@gmail.com wrote: I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen knig...@gmail.com wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread. .. http://groups.google.com/group/twitter-development-talk/browse_thread. .. It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman d...@fishtwits.com wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line Bug? Updates 140 characters return success with prior update payload. See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded no duplicates policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a 200 OK status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the 200 OK response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA
[twitter-dev] Re: API 140 character truncation change?
+1 agreed On Oct 23, 2009, at 7:20 PM, Dewald Pretorius wrote: Instead of all of us having to do fancy tap-dances, the proper solution is for Twitter to issue an error response when a sent tweet is rejected for whatever reason. Dewald On Oct 23, 7:58 pm, AJ Chen cano...@gmail.com wrote: then, comparing the front part (without url at the end) of the status is probably sufficient. -aj On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius dpr...@gmail.com wrote: You cannot compare the status sent with the status returned when the status contains an URL. The returned status contains Twitter's own bit.ly shortened URL instead of the URL your status sent had. Dewald On Oct 23, 6:24 pm, AJ Chen cano...@gmail.com wrote: I noticed this behavior a long time ago (may be a month) and reported the problem on this list, but it did not get any response from the api team. I thought it was a bug, but just realized yesterday that the api probably ignores 140+ chars status update intentionally. but' I'm not sure this is the policy or temporary tactic to reduce workload on api. it would be good that api team can clasify on this issue. to check if this happens or not, you can compare the status sent to api and the status returned from api in your application code. -aj On Fri, Oct 23, 2009 at 1:51 PM, Naveen knig...@gmail.com wrote: Here are two threads related to this issue. http://groups.google.com/group/twitter-development-talk/browse_thread . .. http://groups.google.com/group/twitter-development-talk/browse_thread . .. It is an inconvenient change, not because they changed it, but because they did not announce that the change was happening. On Oct 21, 5:37 am, Dave Sherohman d...@fishtwits.com wrote: On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote: Has anyone else noticed a change in the way that the 140 character limit is enforced via the API? I noticed a change sometime between the 13th and the 16th that is now causing all my 140+ character posts to be rejected by the API. Also a side note is that the api is not returning errors, they return proper responses however they are the proper response for the current status of the account, not the new status that was just attempted to be posted. My users first reported issues arising from this on the 15th, although I didn't identify the cause until the 17th, at which point I asked about it in #Net::Twitter and Marc Mims brought the question here under the subject line Bug? Updates 140 characters return success with prior update payload. See the discussion under that thread for more on it, but the overall upshot is: - This is an intentional (if poorly-announced) change, not a bug. - Status updates are known to be getting silently rejected in this manner both due to exceeding 140 characters and due to violation of the expanded no duplicates policy. - Twitter has not stated whether there are any additional circumstances beyond those two cases in which updates will be silently rejected. - Twitter has not stated any plans regarding adding an indicator for when a 200 OK status update has, in fact, been rejected. I am attempting to compensate for this change by checking the returned status ID against the previous highest-seen ID to determine whether the status returned with the 200 OK response is a new one or the user's pre-existing status. This seems to work, but does not indicate the reason for the silent failure, so I can't report the cause to my users. Andy Freeman has mentioned that, in the case of rejection due to duplication, this is also unsatisfactory in that it does not allow him to identify the original status which was duplicated. -- Dave Sherohman -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA -- AJ Chen, PhD Chair, Semantic Web SIG, sdforum.orghttp://web2express.org Palo Alto, CA
[twitter-dev] Favs not being recorded, or are seriously delayed
Hey guys, It seems when visiting twitter.com, and clicking on the star to add tweets to my favorites list, the favs aren't actually showing in my favorites list. (even 5 mins later) Just mentioning it so it gets on the radar if it's not already. Cheers, Tim.
[twitter-dev] Net::Twitter dev release with Lists API support
I uploaded a development release of Net::Twitter to CPAN with Lists API
support. If you're a perl developer and you're on the Lists beta,
please test it and give me some feedback.
Download it here:
http://search.cpan.org/~mmims/Net-Twitter-3.07999_01/
For documentation see:
perldoc Net::Twitter::Role::API::Lists
You'll need to include the API::Lists trait:
my $nt = Net::Twitter-new(traits = ['API::Lists', ...], ...);
You can always use the user parameter as the first placeholder
argument to any of the API calls. Any or all of the parameters included
in the API URL can be passed as placeholder arguments. Additional
arguments are passed by name in a HASH ref as the final argument. Any
or all parameters can be passed in the HASH ref.
For example, these calls are equivalent:
my $list = $nt-create_list(perl_api =
{ name = 'test', mode = private }
);
my $list = $nt-create_list({
user = 'perl_api',
name = 'test',
mode = 'private',
});
In my own testing, I've noticed that the update_list call always returns
a 500 status, even though it succeeds. That's probably a Twitter bug
that will be worked out.
The Lists API support is experimental. It will very likely change
before a final release. Feedback welcome.
-Marc
[twitter-dev] Re: linespaces / whitespace being removed: bug or feature?
On Tue, Oct 20, 2009 at 5:13 PM, Chad Etzel c...@twitter.com wrote: Just to follow up. We have determined that this is a bug and the engineering team is working to figure out how this snuck in. I'm afraid I don't have an ETA on a fix, but we are working on it. FYI how this snuck in is fairly suspicious, given that there had been some fairly prominent use of whitespace just a few hours before this bug appeared: http://favrd.textism.com/tweet/4998900426 http://favrd.textism.com/tweet/4999223282 I'm not alone in thinking the timing is suspicious, especially if this wasn't some quickly undoable change. It works one way for years, then accidentally gets changed but you can't figure out what happened or how to undo it? TjL
[twitter-dev] Re: Deprecation Notice: pagination on several methods is being replaced with cursoring on October 26, 2009
Bump. Anyone know if page deprecation still scheduled to happen on Oct. 26th? On Oct 22, 3:17 am, Rich rhyl...@gmail.com wrote: I hope not, Apple are being especially slow at approving my update at the moment that includes the cursor changes! On Oct 22, 3:20 am, DustyReagan dustyrea...@gmail.com wrote: Is page deprecation still scheduled to happen on Oct. 26th? Is this deprecation happening on all methods that have the cursor parameter enabled? -Dusty On Oct 8, 5:26 am, Kyle Mulka repalvigla...@yahoo.com wrote: Will thepageparameter on /statuses/user_timeline (or on any of the other timeline methods) be deprecated as well?https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-statuses-us... I've noticed a lot of failures on /statuses/user_timeline recently. Instead of thepageparameter, is it better to use max_id? -- Kyle Mulkahttp://twilk.com-putyour friends faces on your Twitter background On Sep 24, 8:47 pm, Alex Payne a...@twitter.com wrote: Hi, Recently, we documented a new pagination mechanism for our social graph methods, /friends/ids and /followers/ids. Traditional page-based pagination doesn't dovetail with our recent backend changes, and we've now exposed acursor-based pagination mechanism that's far more reliable. Today, we've documented that this new pagination mechanism is also available for the /statuses/friends and /statuses/followers methods. With that change, we're setting a hard deprecation date for traditional pagination on these four methods: October 26th, 2009. That's over a month from now. Once deprecated, we'll simply ignore the page parameter if it's sent by a client, and you'll get the default number of items for the method you're calling. For more information, seehttp://apiwiki.twitter.com/Twitter-API-Documentation. Thanks. -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
