[twitter-dev] Re: Developing WETweet and questions on Following and Un-Following people through the API
Jeff, The friendship methods will allow you to create and destroy friendships on the behalf of authenticated users. Their usage is explained at [1]. These methods allow you to follow and unfollow users. Notification methods are not necessary unless you would like to enable/disable device notification. If you would like a more complete explanation on the differences between following and notification I would be happy to help explain that. The error case for protected users isn't explicit. You will have to parse the returned user element results [2] and look for a true value in the protected element. For instance, in xml format: protectedtrue/protected Lastly, I know a professor who teaches a class where students work on projects promoting computing accessibility. If you feel this is a large enough project that a student could get involved, I can introduce you to the professor so you two can discuss if he has any students who may would be able to contribute. Contact me off the board (do...@igudo.com) if this interests you. [1] - http://apiwiki.twitter.com/REST+API+Documentation#FriendshipMethods [2] - http://apiwiki.twitter.com/REST+API+Documentation#Basicuserinformationelement Thanks, Doug @dougw On Wed, Mar 4, 2009 at 9:26 AM, Jeff Bishop jeff.bis...@gmail.com wrote: Hello, I am developing a Twitter client titled WETweet. The purpose of this client is to provide blind users using the Window-Eyes screen reader a better and more rich experience using Twitter. I had a question about automating the creation of friend relationships and following and un-following people. Which methods of the Twitter API and in what order should be used? What kind of error conditions will be returned when attempting to follow protected users? If one uses the Friend methods to follow someone does the Notification methods need to be utilized? I found the documentation a bit unclear on the path to take here. Thanks for everyone's help. Jeff -- Doug Williams do...@igudo.com http://www.igudo.com
[twitter-dev] Intercepting replies in realtime
I've seen the doc on the replies API method in the documentation. Is there a way to capture a reply automatically in order to process it in real-time? Perhaps a callback.
[twitter-dev] Tracking the friend timeline
Over at http://birdhive.net, we track our friend timeline to find people who have marked tweets with the #bh hashtag. Until very recently, I thought that passing the optional since parameter in my request would return all tweets in that timespan. It was only recently that I realised it just returned the default 20 tweets, filtered to fit into that timespan. A big goof on my part. As a result, we've been missing some tweets. In response, I've set the count parameter to it's maximum of 200 and have increased the frequency of my cron script. But this still seems shaky. I feel I should be using the search API, but can't find a way to filter results to only show a friends tweets. Any suggestions?
[twitter-dev] Bug: in_reply_to_screen_name
field: in_reply_to_screen_name exists for statuses /statuses/friends/USERNAME.xml but in /statuses/friends/USERNAME.json it does not. thank you.
[twitter-dev] Re: 500 internal error
Nope its just running in a safari browser adn it works great.
Im using this javascript function for Base64
http://www.webtoolkit.info/javascript-base64.html.
here is the full code again:
function setTwitterStatus(twitterStatus){
var twitterStatus = 'status='+twitterStatus;
var req = new XMLHttpRequest();
req.open('POST', 'http://twitter.com/statuses/update.json',1);
req.setRequestHeader('Authorization', 'Basic
'+Base64.encode(twitterUsername+':'+twitterPassword));
req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
req.onreadystatechange = function(){
if(req.readyState ==4){
//could do something here
}
}
req.send(twitterStatus);
}
Please ensure that you rename the twitterUsername and twitterPassword as i
do that some where else.
If you still struggle please don't hesitate to contact me to help you
working this out.
Regards
Paul Haenel
2009/3/3 Chad Etzel jazzyc...@gmail.com
I'm curious.
I have been trying to get a client-side javascript posting mechanism
to work for a long time, but gave up since cross-domain
xmlhttprequests are usually disallowed. How did you get this to work?
I just tried your code snippet out, and sure enough, got a permission
denied error in my console, and no request was sent.
Is it running in something other than a browser?
-Chad
On Wed, Feb 25, 2009 at 5:48 AM, Paul Haenel paul.hae...@googlemail.com
wrote:
Hi,
Im getting a internal error which i execute this JavaScript function:
function setTwitterStatus(twitterStatus){
var twitterStatus = 'status='+twitterStatus;
alert(twitterStatus);
var req = new XMLHttpRequest();
req.open('POST', 'http://twitter.com/statuses/update.json',1);
req.setRequestHeader('Authorization', 'Basic '+Base64.encode
(twitterUsername+':'+twitterPassword));
req.onreadystatechange = function(){
if(req.readyState ==4){
alert(req.responseText);
}
}
req.send(twitterStatus);
}
twitter status is is a plain text like hello or is working hard.
here is s acopy of the response:
Status: 500 Internal Server Error
Content-Type: text/html
htmlbodyh1500 Internal Server Error/h1/body/htmlStatus:
500 Internal Server Error
Content-Type: text/html
htmlbodyh1500 Internal Server Error/h1/body/html
Any help appreciated.
Thanks Paul
--
Regards
Paul Haenel
Sent from: London Greater London United Kingdom.
[twitter-dev] Re: Developing WETweet and questions on Following and Un-Following people through the API
Doug, Thank you. One question though. If I try to follow someone that is protected will the Twitter API go ahead and submit the request without a problem or do I need to do something different? I understand I could check the protected node for its value to determine if the user was a protected one. Jeff - Original Message - From: Doug Williams To: twitter-development-talk@googlegroups.com Sent: Wednesday, March 04, 2009 8:27 AM Subject: [twitter-dev] Re: Developing WETweet and questions on Following and Un-Following people through the API Jeff, The friendship methods will allow you to create and destroy friendships on the behalf of authenticated users. Their usage is explained at [1]. These methods allow you to follow and unfollow users. Notification methods are not necessary unless you would like to enable/disable device notification. If you would like a more complete explanation on the differences between following and notification I would be happy to help explain that. The error case for protected users isn't explicit. You will have to parse the returned user element results [2] and look for a true value in the protected element. For instance, in xml format: protectedtrue/protected Lastly, I know a professor who teaches a class where students work on projects promoting computing accessibility. If you feel this is a large enough project that a student could get involved, I can introduce you to the professor so you two can discuss if he has any students who may would be able to contribute. Contact me off the board (do...@igudo.com) if this interests you. [1] - http://apiwiki.twitter.com/REST+API+Documentation#FriendshipMethods [2] - http://apiwiki.twitter.com/REST+API+Documentation#Basicuserinformationelement Thanks, Doug @dougw On Wed, Mar 4, 2009 at 9:26 AM, Jeff Bishop jeff.bis...@gmail.com wrote: Hello, I am developing a Twitter client titled WETweet. The purpose of this client is to provide blind users using the Window-Eyes screen reader a better and more rich experience using Twitter. I had a question about automating the creation of friend relationships and following and un-following people. Which methods of the Twitter API and in what order should be used? What kind of error conditions will be returned when attempting to follow protected users? If one uses the Friend methods to follow someone does the Notification methods need to be utilized? I found the documentation a bit unclear on the path to take here. Thanks for everyone's help. Jeff -- Doug Williams do...@igudo.com http://www.igudo.com
[twitter-dev] Re: Suspended or Deleted Account Feed ...
We had a conversation about this about a week ago which led to a feature request you may want to 'star': http://code.google.com/p/twitter-api/issues/detail?id=311
[twitter-dev] Re: Rate limiting message in search
Thanks Paul,
I'll log your message here as an issue and see what I can do. And as
far as WebException is concerned,
you can just cast its Response property to HttpWebResponse rather than
go digging in the header. That's exactly what I do to retrieve the
root's Response object. So that means you can just cast that to
HttpWebResponse and get the StatusCode.
catch(WebException ex)
{
if (ex.Response != null ex.Response is HttpWebResponse)
{
return ex.Response;
}
}
On Mar 3, 1:06 pm, Paul Kinlan paul.kin...@gmail.com wrote:
Thats pretty much where I am handling the 503, my client code intercepts the
exception and then inspects the header. The other thing I noticed, and it
is probably not best on this list is that you use WebRequest which raises a
WebException, and you can't get the 503 out of it easily (at least from what
I understand), where as HttpWebRequest raises HttpWebException which you can
directly check for a 503 error.
Anyway, I really enjoy using Tweet# and if any .Net devs out there need a
.Net Twitter library this is the one I recommend.
Paul
2009/3/3 Dimebrain daniel.cre...@gmail.com
Thanks for the feedback; right now you can get at the response in
instance.Root.Response (where instance is your FluentTwitter query),
which will give you the instance of the last response returned. I'll
look at this closer (unless you have a patch already of course).
Daniel
On Mar 3, 11:28 am, Paul Kinlan paul.kin...@gmail.com wrote:
Hi Daniel,
I am using tweet# a lot, and it would be good if you catch the 503 error
status on the rate limited requests (including the Retry-After header in
the
response), I have had to implement it in tweet# for our product.
Kind Regards,
Paul
2009/3/3 Dimebrain daniel.cre...@gmail.com
I have experienced sending search requests out which return a plain
string, rather than JSON representing a twitter error. It's this:
You have been rate limited. Enhance your calm.
a) What is the rate limiting based on, IP or client? What is the
limit? I develop a Twitter library (tweetsharp) and by default I send
the tweet# credentials along with the call. If this means that anyone
using my library will be rate limited because of that header
information, I need to know so I can force my users to provide their
own credentials so that the library isn't unusable in this area, and
b) Can we get his as XML, JSON and not a plain string?
[twitter-dev] Re: Developing WETweet and questions on Following and Un-Following people through the API
Jeff, In my tests, the request was successfully set, and my protected test user was notified of a pending friend request. Regards, Doug @dougw On Wed, Mar 4, 2009 at 11:12 AM, Jeff Bishop jeff.bis...@gmail.com wrote: Doug, Thank you. One question though. If I try to follow someone that is protected will the Twitter API go ahead and submit the request without a problem or do I need to do something different? I understand I could check the protected node for its value to determine if the user was a protected one. Jeff - Original Message - *From:* Doug Williams do...@igudo.com *To:* twitter-development-talk@googlegroups.com *Sent:* Wednesday, March 04, 2009 8:27 AM *Subject:* [twitter-dev] Re: Developing WETweet and questions on Following and Un-Following people through the API Jeff, The friendship methods will allow you to create and destroy friendships on the behalf of authenticated users. Their usage is explained at [1]. These methods allow you to follow and unfollow users. Notification methods are not necessary unless you would like to enable/disable device notification. If you would like a more complete explanation on the differences between following and notification I would be happy to help explain that. The error case for protected users isn't explicit. You will have to parse the returned user element results [2] and look for a true value in the protected element. For instance, in xml format: protectedtrue/protected Lastly, I know a professor who teaches a class where students work on projects promoting computing accessibility. If you feel this is a large enough project that a student could get involved, I can introduce you to the professor so you two can discuss if he has any students who may would be able to contribute. Contact me off the board (do...@igudo.com) if this interests you. [1] - http://apiwiki.twitter.com/REST+API+Documentation#FriendshipMethods [2] - http://apiwiki.twitter.com/REST+API+Documentation#Basicuserinformationelement Thanks, Doug @dougw On Wed, Mar 4, 2009 at 9:26 AM, Jeff Bishop jeff.bis...@gmail.com wrote: Hello, I am developing a Twitter client titled WETweet. The purpose of this client is to provide blind users using the Window-Eyes screen reader a better and more rich experience using Twitter. I had a question about automating the creation of friend relationships and following and un-following people. Which methods of the Twitter API and in what order should be used? What kind of error conditions will be returned when attempting to follow protected users? If one uses the Friend methods to follow someone does the Notification methods need to be utilized? I found the documentation a bit unclear on the path to take here. Thanks for everyone's help. Jeff -- Doug Williams do...@igudo.com http://www.igudo.com -- Doug Williams do...@igudo.com http://www.igudo.com
[twitter-dev] Re: Intercepting replies in realtime
2009/3/4 kprobe goo...@kprobe.com I've seen the doc on the replies API method in the documentation. Is there a way to capture a reply automatically in order to process it in real-time? Perhaps a callback. Look at www.gnip.com. -Stuart -- http://stut.net/
[twitter-dev] Re: Intercepting replies in realtime
There is currently no callback, subscription or push pattern available for API methods. Thanks, Doug @dougw On Wed, Mar 4, 2009 at 10:26 AM, kprobe goo...@kprobe.com wrote: I've seen the doc on the replies API method in the documentation. Is there a way to capture a reply automatically in order to process it in real-time? Perhaps a callback. -- Doug Williams do...@igudo.com http://www.igudo.com
[twitter-dev] Re: Tracking the friend timeline
2009/3/4 Nial nia...@gmail.com Over at http://birdhive.net, we track our friend timeline to find people who have marked tweets with the #bh hashtag. Until very recently, I thought that passing the optional since parameter in my request would return all tweets in that timespan. It was only recently that I realised it just returned the default 20 tweets, filtered to fit into that timespan. A big goof on my part. As a result, we've been missing some tweets. In response, I've set the count parameter to it's maximum of 200 and have increased the frequency of my cron script. But this still seems shaky. I feel I should be using the search API, but can't find a way to filter results to only show a friends tweets. Any suggestions? http://apiwiki.twitter.com/Search+API+Documentation#Search -Stuart -- http://stut.net/
[twitter-dev] Re: Bug: in_reply_to_screen_name
Adrian, There is an issue that was just opened for this: http://code.google.com/p/twitter-api/issues/detail?id=323 As always, star to show your priority. Thanks, Doug @dougw On Wed, Mar 4, 2009 at 7:12 AM, Adrian spiritpo...@gmail.com wrote: field: in_reply_to_screen_name exists for statuses /statuses/friends/USERNAME.xml but in /statuses/friends/USERNAME.json it does not. thank you. -- Doug Williams do...@igudo.com http://www.igudo.com
[twitter-dev] Re: Tracking the friend timeline
If you don't want to limit it to only your friends you could just search for #bh and do what you will with the results... unless there is a conflicting #bh tag being used for something else? -Chad On Wed, Mar 4, 2009 at 9:49 AM, Nial nia...@gmail.com wrote: Over at http://birdhive.net, we track our friend timeline to find people who have marked tweets with the #bh hashtag. Until very recently, I thought that passing the optional since parameter in my request would return all tweets in that timespan. It was only recently that I realised it just returned the default 20 tweets, filtered to fit into that timespan. A big goof on my part. As a result, we've been missing some tweets. In response, I've set the count parameter to it's maximum of 200 and have increased the frequency of my cron script. But this still seems shaky. I feel I should be using the search API, but can't find a way to filter results to only show a friends tweets. Any suggestions?
[twitter-dev] Re: in reply to metadata missing for manual replies
Back and forth with atebits over e-mail: I, personally, found the false positives much more acceptable than the current situation where you have to hunt for originating tweets for false negatives. Doing anything interesting like automatically crawling conversation webs is flat out impossible with false positives, and only an annoyance with false negatives. It is a lie that it is impossible with false positives. With false positives, you can *always* crawl all conversation webs when they are correct, even when auto-linked, and you can easily tell when the auto- linking targeted an incorrect tweet. With false negatives, it's a lot worse because sometimes you can't crawl a correct conversation web at all. It is *far* faster for a user to identify a false positive then a user to hunt for a false negative. Again, it takes 1 second to identify that the auto-linking was incorrect, but 10 seconds to MINUTES to find the correct reply to a false negative, especially if the user is a prolific tweeter. Again, the new in_reply_to_status_id is relatively new, so with most people using that, the conversation webs will largely be correct. But when someone forgets to use the reply swoosh, I'd rather have Twitter auto-link the reply even if it causes some conversation webs to be falsely connected. I would also argue that false negatives should be blamed on crappy clients. I know that a few clients (up until recently) didn't set the in_reply_to_status_id AT ALL, even for tweets where the user *explicitly* replies to a particular tweet (i.e. clicked the reply button next to it). I'm sorry, but also no. I have seen many people who are using conforming clients not jump through the UI hoops to perform a correct reply, both out of habit (i.e.: constant violators), or out of error (i.e.: just a one-time mistake). I prefer to take both kinds of human error out of the question via auto-linking. The false negatives were caused by people not used to the fact that they have to perform additional UI actions because of the change. To force users to do something to get a correct reply is stupid, in contrast to letting them do what they naturally do (which is how it was before). There will be some growing pains, which will last as long as people continue to use crappy clients. After that, many really interesting things become possible. No, again, people are already using conforming clients. And, no, again, even with false positives, really interesting things are *already* possible. False positives do not inhibit any of those really interesting things. That sounds rather hackish. I think the correct long term solution is to leave it exactly as-is. The other thing I'd like to point out is that with the old system, there was no way to express a general reply. By that I mean a reply to someone that *isn't* in response to a particular tweet... more of just a directed tweet - which is a legitimately useful thing to express (and I'm not sure how you would express it using your workaround). *facepalm* I am well aware that you couldn't express a general reply with the old system. Stop convincing yourself that I'm advocating to go back to the old way. With my way, you do it exactly as you do it now, and as you did it before: you simply type in @atebits and then your message. Twitter will auto-link it, and then display the link if the user's prefs say to display auto-links. The user can figure out whether the context is correct or not. The point is that humans are much more capable of determining whether context is correct or not, but computers are far better at establishing any sort of context in the first place. So the most effective way to establish the best context is to let both computers and humans do what they are best at doing. Computers will provide as much context as possible, and humans will throw out the context that isn't good. -- Simone
[twitter-dev] Re: Consistent 502 errors for users with large friend follower lists
Protocol Buffers is yet another RPC scheme that requires compilation of the data types. If on the other hand you define simple data types this can be much simpler and finessed, and including dealing with such RPC issues as endian-ness. wondering if is there any sort of compression of XML that is done solely in utf8 encoding (rather than binary)? Also, I'm not wanting a solution that involves paging the data, since the data I'm after is the entire list. Breaking up the data does nothing for me except take longer and increase bandwidth needs. I want the entire chunk with the least cost to Twitter and myself of time and cpu/bandwidth... so smaller data is better. Paging is also bad because of it will cost me as a rate-limiting penalty... unless the page sizes are really large... 8-) Speaking of which, BarackObama is the worst by far with 600k+ lists... but is the trend only going to get worse? When/if Twitter really gets popular will we be seeing users with 1mil users lists? At some point, even with a binary RPC scheme and data compression this can get expensive... (me thinks caching on my side is unavoidable) On Tue, Mar 3, 2009 at 1:13 PM, Alex Payne a...@twitter.com wrote: That would definitely require us to weigh our current knowledge of Thrift vs Protocol Buffers. I'll think about it. On Tue, Mar 3, 2009 at 12:42, Dossy Shiobara do...@panoptic.com wrote: On 3/3/09 3:07 PM, Alex Payne wrote: We're fully aware of what Protocol Buffers are their intended use. We use Thrift, Facebook's clone of Protocol Buffers. You might note the use of the world internal in the material you quoted. Quoting from http://code.google.com/apis/protocolbuffers/docs/faq.html: We would like to provide public APIs that accept protocol buffers as well as XML, both because it is more efficient and because we're just going to convert that XML to protocol buffers on our end anyway. Their use of the word internal simply clarifies where they _currently_ use it, not its limitation. Could Twitter be the first service to offer protocol buffers? Sure. I guess you're saying it's not going to happen, though. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: RESTful API to unshorten URL's from twitter
On Wed, Mar 4, 2009 at 12:38 PM, Nick Halstead nickhalst...@gmail.comwrote: We have tried to stick very closely to the RESTful + twitter style API The documentation is here - http://www.tweetmeme.com/apidoc.php An example of the url fetcher - http://api.tweetmeme.com/url_info?url=http://is.gd/lznv We also have two methods that let you fetch the most popular + the most recent stories. Cool... I'm doing the same kind of thing, but instead of trying to do it comprehensively, I'm relying on predictive modeling and social network analysis to minimize the data. I'm able to identify most, if not all, of the popular URLs by making a system that is smart about who to track and how often. How comprehensive is your data? Are you trying to do the entire firehose? Would love to get feedback on what other data mining methods we could expose. By offering the API, you'll make it much easier for people to build on top of it. Maybe the best thing you could do is to make that service as complete and robust as possible. I think the future of things like this are in vertical-ization and personalization. Nick
[twitter-dev] Re: RESTful API to unshorten URL's from twitter
Nick Halstead wrote: Today we launched an API for tweetmeme, for those who havent tried it, we aggregate all the twitter URL's to rank the most popular stories. Well the upside of this is that we have massive database of all the short URL's - and where they resolve to, included in this we also go and grab the page that it points at, and so we fetch the title, category of content, and a few other bits. We have tried to stick very closely to the RESTful + twitter style API The documentation is here - http://www.tweetmeme.com/apidoc.php An example of the url fetcher - http://api.tweetmeme.com/url_info?url=http://is.gd/lznv We also have two methods that let you fetch the most popular + the most recent stories. Would love to get feedback on what other data mining methods we could expose. It is pretty cool. I don't want to be a pain, but story is not written storie: http://api.tweetmeme.com/popular.xml - pain to fix this one though if you already have published the api.
[twitter-dev] regex for smiley indexing?
Hey Twitter folks I *love* that you guys index messages by smiley vs. frowny emoticons! It looks like you normalize a wide range of happy and sad emoticons together. I'm doing some searches in [[ :) ]] and trying to then identify what the original smiley in the message was and it's a little tricky. For example, for happy, I've seen all of these: :-) :D ^_^ =) :) : ) ;) I have some regexes to extract them them -- attached if anyone's curious -- but I'm sure i'm missing plenty, and I sometimes identify some that don't belong. Are you guys using a regex or something at index time? Does it change much? Would you mind sharing? cheers, :) ... or should i say ^_^ Brendan [ anyall.org ] emoticons.py Description: Binary data
[twitter-dev] Re: regex for smiley indexing?
I would assume that they do use a simple OR. Nicole -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon: http://tinyurl.com/6at9c5 http://mit140zeichen.de - http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimon https://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Re: in reply to metadata missing for manual replies
On Wed, Mar 4, 2009 at 4:38 PM, atebits loren.brich...@gmail.com wrote: 1. If a client is making users jump through hoops to reply to a specific tweet, the client is doing it wrong. [snip] The end of auto-linking was a fantastic change for two reasons: 1. it keeps everything simple (no new settings or flags or functionality), 2. it allows developers to trust in_reply_to_status_id, paving the way for some *really* fantastic stuff down the road. Agreed on both points. I like the possibilities for actual conversation threading (not yet realized in summize searches but you can see the potential) With the exception that m.twitter.com really needs to get a reply button that works properly. If people are too lazy, well... tough. Just like proper mail filtering/threading, if they can't be bothered to figure out how it works, they'll lose some of the advantages that the software can provide for them. If they are using outdated software, then all sorts of things may break, including favorites (broken in an earlier version of Twitterrific when the API changed). Again, tough. There *should* be a way to start a conversation chain without setting an in-reply-to being added where it doesn't belong. That's where it makes sense that you would type in @NAME by hand. Twitter shouldn't be held hostage to the way it used to be for a feature which was clearly broken by indicating a relationship between two posts when there was none. Neither should they be held hostage to Users are too lazy to do it the right way. And yes, if their twitter client makes real replies too hard, they should be updated to make it easier or they should fall into disuse. TjL
[twitter-dev] Re: regex for smiley indexing?
On Mar 4, 1:52 pm, Nicole Simon nee...@gmail.com wrote: I would assume that they do use a simple OR. Sure, but an OR of what?
[twitter-dev] oauth not working via https://twitter.com
For example: https://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU that url doesn't work (returns stanard twitter page not found), but this one does http://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU This doesn't always seem to be the case, but any thoughts on why?
[twitter-dev] Re: oauth not working via https://twitter.com
Hi all, This is related to the login error (http://status.twitter.com/post/83602310/problems-logging-in ) and people are working on it. Thanks; — Matt Sanford On Mar 4, 2009, at 03:32 PM, dean.j.robinson wrote: For example: https://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU that url doesn't work (returns stanard twitter page not found), but this one does http://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8GyzKpnREj9oKf6aG6f3pU This doesn't always seem to be the case, but any thoughts on why?
[twitter-dev] Re: RESTful API to unshorten URL's from twitter
We have already implmented Tweetmeme's API in our test site and will pish it live on Friday. Good job Nick. Thanks in advance Sam www.twitblogs.com/ssethi This email is: [ ] bloggable [ ] twittable [ ] ask first [X] private Sent from: Poplar Eng United Kingdom. 2009/3/4 Nick Halstead nickhalst...@gmail.comhttps://www.linkedin.com/addcontacts?addresses=nickhalst...@gmail.comaddByHand=Add+these+contactsbatchID=0context=0membersOnly=truecurrentPage=1goback=.oca_1_false_0_0 Today we launched an API for tweetmeme, for those who havent tried it, we aggregate all the twitter URL's to rank the most popular stories. Well the upside of this is that we have massive database of all the short URL's - and where they resolve to, included in this we also go and grab the page that it points at, and so we fetch the title, category of content, and a few other bits. We have tried to stick very closely to the RESTful + twitter style API The documentation is here - http://www.tweetmeme.com/apidoc.php An example of the url fetcher - http://api.tweetmeme.com/url_info?url=http://is.gd/lznv We also have two methods that let you fetch the most popular + the most recent stories. Would love to get feedback on what other data mining methods we could expose.
[twitter-dev] Re: oauth not working via https://twitter.com
Thanks for the speedy response Matt. Much appreciated. On Mar 5, 10:49 am, Matt Sanford m...@twitter.com wrote: Hi all, This is related to the login error (http://status.twitter.com/post/83602310/problems-logging-in ) and people are working on it. Thanks; — Matt Sanford On Mar 4, 2009, at 03:32 PM, dean.j.robinson wrote: For example: https://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8G... that url doesn't work (returns stanard twitter page not found), but this one does http://twitter.com/oauth/authorize?oauth_token=OMxcOPndHoO57JMFURt8Gy... This doesn't always seem to be the case, but any thoughts on why?
[twitter-dev] Re: in reply to metadata missing for manual replies
On 4 Mar, 14:25, TjL luo...@gmail.com wrote: There *should* be a way to start a conversation chain without setting an in-reply-to being added where it doesn't belong. That's where it makes sense that you would type in @NAME by hand. Twitter shouldn't be held hostage to the way it used to be for a feature which was clearly broken by indicating a relationship between two posts when there was none. Neither should they be held hostage to Users are too lazy to do it the right way. As I have attempted to explain to atebits and to others, I AM NOT ADVOCATING TO GO BACK TO THE WAY IT USED TO BE. I am advocating for a *compromise* solution. I *understand* the need for there to be an accurate way to follow conversation chains, and I *like* that the new way allows for this. But the approximate context that the previous method used should *also* NOT be tossed out. If an extra flag is set in addition to the in_reply_to_status_id metadata, then BOTH methods can be used. Clients which want to throw out any non-exact context can accept only that data which includes the exact flag, and clients which want as much context as possible can simply ignore the flag. BOTH METHODS CAN BE DONE AT ONCE. And yes, if their twitter client makes real replies too hard, they should be updated to make it easier or they should fall into disuse. This is just arrogant. This is completely false. When someone wants to reply to me, typing five characters, @simX is *far* faster than moving your mouse to target a tiny little reply swoosh. It takes a whole second to move your hand to the mouse, when you can type those 5 characters in under a second if you're a fast typer. Saying that users who refuse to jump through the UI hoops are somehow inferior is lame and condescending. Not only that, but humans often make mistakes and simply forget to target a specific tweet. Losing the context because of simple human error is unnecessary. The @reply syntax was created organically by users. It was not created by Twitter. As such, it represents more of how users actually want to interact with Twitter. That functionality should be preserved AS WELL AS providing a way to accurately follow conversation chains. The mere fact that there are genuine replies that don't have the in_reply_to_status_id metadata set demonstrates that the new interface should not completely replace the old functionality. -- Simone
