[twitter-dev] Re: reading reply status post
On Fri, Nov 6, 2009 at 12:28 PM, MuratMetu wrote: > > Hello, I am new to twitter dev, is there any way to read replies > posted to my account from api like @MyUsername ..? Status request > reads only the statuses. I want to do it from Twitter API not from 3. > party Check out this cool site: http://apiwiki.twitter.com/Twitter-API-Documentation -damon
[twitter-dev] Pyramid scheme to gain followers
Wow - http://www.tweetpopular.com Sadly I bet a bunch of users go for this too.
[twitter-dev] Re: Mobile Twitter Client & OAuth
When you use browser oAuth it redirects to your browser with the parameter oauth_token. Simply redirect that back to your own app including that parameter and get your app to read it. On Nov 6, 8:43 am, srikanth reddy wrote: > @Rich > i didn't get this. When you set browser auth, there is no pin to retrieve > (if i am not wrong) and i am assuming you are retrieving access > tokens/secrets directly.So after redirecting to your own server how exactly > are you going to retrieve the values for that Particular client? Can you > elaborate? > > On Fri, Nov 6, 2009 at 1:01 PM, Rich wrote: > > > You can do exactly that already. Set it to browser auth, redirect it > > to your own webserver and get your webserver to redirect to your own > > url scheme, forwarding on the callback token. > > > Trust me, it will work just fine! > > > On Nov 6, 5:20 am, Ji Lee wrote: > > > Hi, > > > > It seems that the current OAuth for desktop apps require that the user > > > copy the 7-digit number, and paste into the client. This is fine for > > > the desktop, but it doesn't work too well for the mobile device, as > > > copy/paste is a rather cumbersome to do... Flickr OAuth seems to > > > provide a mechanism which allows the desktop client to retrieve the > > > token using a separate URL. > > > > Is there a URL for retrieving the token after user return to the > > > client application? Would commerial key help? > > > > Another possibility is to allow for a callback URL scheme, such as > > > "myclient://" as the callback URL, which my app could register itself > > > to handle. Curretly, the twitter website does not seem to accept such > > > URLs. > > > > Thanks, > > > > -Ji
[twitter-dev] Re: api.twitter.com not returning compressed data
On Thu, Nov 5, 2009 at 8:20 PM, Marcel Molina wrote: We've confirmed this and reported it to our operations team. We've identified the problem and are actively fixing it. Thanks for the detailed report. I'll let you know when the gzip compression is restored. This configuration has been fixed as of 1:30AM PST. -- John Twitter Ops
[twitter-dev] Re: PHP Libraries for OAuth
The new 2.0 version provides an alternative API to the __call method :). http://wiki.github.com/jmathai/twitter-async#usage_and_examples On Nov 1, 3:21 pm, Michael Mokrysz wrote: > Thanks to both of you, having taken a better look at epitwitter's code > I'd have to agree that's it's best to switch. I still like to be able > to pretty much copy and paste urls from the documentation rather than > having think how to convert it into the (albeit ingenious) conversion > method EpiTwitter uses so I think I'll probably rewrite the __call > function a little but keep the rest of the code.
[twitter-dev] Re: PHP Libraries for OAuth
I pushed the 2.0 version of the library to Github and it includes quite a few changes. Docs: http://wiki.github.com/jmathai/twitter-async Release Notes: http://wiki.github.com/jmathai/twitter-async/twitter-async-20-release-notes # Added a new (preferred) API You can now use get, post, delete, get_basic, post_basic and delete_basic. Details here # No longer asynchronous by default Most people were using it synchronously and didn’t understand why you had to access a response parameter to ensure the call completed. useAsynchronous(true) should be used if you want to use it that way or hard code the default value in _EpiTwitter.php) # Revamped the exceptions Details on the new exception hierarchy # Added support for versioned URLs # Fixed lots and lots of bugs # Exposed response headers On Nov 2, 2:25 pm, jmathai wrote: > I think it will benefit all users of the library to document the > method names for every call. While it's somewhat trivial to determine > the method names it still required just an ounce of brain power. That > ounce should be save for other tasks :). > > It's been on my todo list to document them all, but I've been lazy :) > > On Nov 1, 3:21 pm, Michael Mokrysz wrote: > > > Thanks to both of you, having taken a better look at epitwitter's code > > I'd have to agree that's it's best to switch. I still like to be able > > to pretty much copy and paste urls from the documentation rather than > > having think how to convert it into the (albeit ingenious) conversion > > method EpiTwitter uses so I think I'll probably rewrite the __call > > function a little but keep the rest of the code.
[twitter-dev] Re: Question about versioning
We do not have plans to support minor versions initially. We're going to start with the simplest versioning scheme possible and then expand it to include minor versions when the need arises. So as of right now version 1 already exists, at http://api.twitter.com/1. As for whether it should be considered "stable", I'd say it's very close to being so. I've been using it exclusively on my Twitter clients for several months. Since announcing it publicly a couple weeks ago the only reports of irregularities have been around server configuration (e.g. some requests over ssl getting an untrusted cert error and requests for gzipped responses not being configured correctly). As for the behavior of the API it should be 100% compatible with the non versioned twitter.com API. On Thu, Nov 5, 2009 at 7:36 AM, DeWitt Clinton wrote: > Hi all, > I'd like to sync the version numbers and release cycles of a few twitter > libraries (python-twitter and java-twitter) up with the version of the > Twitter API itself. I'll admit that I've fallen way behind on > the maintenance of each, partly because the Twitter API itself is a moving > target (not a bad thing, just hard to keep in sync with). > What's the expected timing of when we can rely on a stable versioned > endpoint for v1, v2, etc, and bleeding-edge API versions? In theory we'd do > parallel releases on major/minor releases, and keep a dev branch open for > the latest-and-greatest-and-beta-est version of the Twitter API. > -DeWitt -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: /statuses/retweeted_to_me.xml?count=200 yields HTTP 500
Thanks for the report. Will try to recreate & look into it. On Fri, Nov 6, 2009 at 12:35 AM, Dave Briccetti wrote: > > BY ME: http://twitter.com/statuses/retweeted_by_me.xml?count=200 works > just fine. > > TO ME: /statuses/retweeted_to_me.xml?count=10 works fine. > > User dcbriccetti > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Mobile Twitter Client & OAuth
@Rich i didn't get this. When you set browser auth, there is no pin to retrieve (if i am not wrong) and i am assuming you are retrieving access tokens/secrets directly.So after redirecting to your own server how exactly are you going to retrieve the values for that Particular client? Can you elaborate? On Fri, Nov 6, 2009 at 1:01 PM, Rich wrote: > > You can do exactly that already. Set it to browser auth, redirect it > to your own webserver and get your webserver to redirect to your own > url scheme, forwarding on the callback token. > > Trust me, it will work just fine! > > On Nov 6, 5:20 am, Ji Lee wrote: > > Hi, > > > > It seems that the current OAuth for desktop apps require that the user > > copy the 7-digit number, and paste into the client. This is fine for > > the desktop, but it doesn't work too well for the mobile device, as > > copy/paste is a rather cumbersome to do... Flickr OAuth seems to > > provide a mechanism which allows the desktop client to retrieve the > > token using a separate URL. > > > > Is there a URL for retrieving the token after user return to the > > client application? Would commerial key help? > > > > Another possibility is to allow for a callback URL scheme, such as > > "myclient://" as the callback URL, which my app could register itself > > to handle. Curretly, the twitter website does not seem to accept such > > URLs. > > > > Thanks, > > > > -Ji >
[twitter-dev] /statuses/retweeted_to_me.xml?count=200 yields HTTP 500
BY ME: http://twitter.com/statuses/retweeted_by_me.xml?count=200 works just fine. TO ME: /statuses/retweeted_to_me.xml?count=10 works fine. User dcbriccetti
