Re: [twitter-dev] Re: xauth error -1012
> Yes, a...@twitter.com granted my app for xAuth... > Any suggestion on what I should do to fix the issue? > I did all I can and I'm STUCK at the point. A little easy googling (for "NSURLErrorDomain error 1012") turned up http://stackoverflow.com/questions/501231/can-i-use-nsurlcredentialstorage-for-http-basic-authentication, which might be helpful for you. Also, again, some very easy searching in the Xcode docs yields NSURLErrorDomain error -1012 as: NSURLErrorUserCancelledAuthentication Returned when an asynchronous request for authentication is cancelled by the user. This is typically incurred by clicking a “Cancel” button in a username/password dialog, rather than the user making an attempt to authenticate. So it looks like you're getting an auth request in the http response and you're not handling it correctly / at all. So either the auth request is incorrect -- in which case you should probably post the full http request and response to this list -- or you need to handle it. (If you don't know how to handle it, and you can't figure it out from the docs, it's probably a question better suited for an iPhone dev list.) -josh > On Apr 20, 1:27 pm, Taylor Singletary > wrote: >> Hi Sae, >> >> Have you received approval for using xAuth in your application yet by >> emailing a...@twitter.com ? I'm not familiar enough with Objective-C to >> understand the error, but your signature base string and authorization >> header look otherwise correct on first glance. >> >> Taylor Singletary >> Developer Advocate, Twitterhttp://twitter.com/episod >> >> >> >> On Tue, Apr 20, 2010 at 1:13 PM, sae wrote: >> > Hi, >> > I just set up my application for xauth and started testing. >> > It keeps failing with error message: >> >> > Error Domain=NSURLErrorDomain Code=-1012 UserInfo=0x268d70 "Operation >> > could not be completed. (NSURLErrorDomain error -1012.) >> >> > What is this error? Is anything wrong with my app setting, or my >> > parameter may not be correct? >> > Any clue will be really appreciated... >> >> > Here is the copy of signature-base-string and authorization header, >> > which all look ok to me: >> >> > POST&https%3A%2F%2Fapi.twitter.com%2Foauth >> > %2Faccess_token&oauth_consumer_key%3Dxx%26oauth_nonce >> > %3D684B1D0C-4276-47BD-9A43-C31FDDD0DD8A%26oauth_signature_method >> > %3DHMAC-SHA1%26oauth_timestamp%3D1271708678%26oauth_version >> > %3D1.0%26x_auth_mode%3Dclient_auth%26x_auth_password%3Dxx >> > %26x_auth_username%3Dy >> >> > OAuth realm=\"\", >> > oauth_consumer_key=\"\", >> > oauth_signature_method=\"HMAC-SHA1\", >> > oauth_signature=\"rg5s%2BW8wMxSx5MJt0wV3idqjriI%3D\", >> > oauth_timestamp=\"1271708678\", >> > oauth_nonce=\"684B1D0C-4276-47BD-9A43-C31FDDD0DD8A\", >> > oauth_version=\"1.0\"; >> >> > -- >> > Subscription settings: >> >http://groups.google.com/group/twitter-development-talk/subscribe?hl=en >
Re: [twitter-dev] Problem with JSON
It looks like you are implicitly assuming that the OS will send you
chunks of stream data that correspond to single, complete parsable
chunks. That may have worked accidentally because that happened to be
how they arrived in time, but it is definitely unreliable (as you
found). What you should do in connection:didReceiveData: is buffer the
data you received, and split it up yourself by looking for the
delimiters that separate individual tweets, and then parse those
individual tweets.
-josh
On Sun, Apr 18, 2010 at 5:29 AM, Carl Knott wrote:
> I have developed an iPhone app that connects to the streaming API the
> app was running correctly for 2 months but since yesterday it has not! I can
> still receive a response from the stream but now I can not parse the JSON
> correctly... My parser believes that the stream is incorrectly structured. I
> get a few correctly structured results and then I get errors. Is it a
> problem at twitters end or mine? Below is a snippet of my code.
> To initialize the HTTP request:
> request = [NSURLRequest requestWithURL:[NSURL URLWithString:[NSString
> stringWithFormat:
> @"http://%@:%@@stream.twitter.com/1/statuses/filter.json?track=%@";,
> [[NSUserDefaults standardUserDefaults] stringForKey:@"UsernameKey"],
> [[NSUserDefaults standardUserDefaults] stringForKey:@"PasswordKey"],
> searchFormat]] ];
>
> - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData
> *)data {
> NSString *responseString = [[[NSString alloc] initWithData:data
> encoding:NSUTF8StringEncoding] autorelease];
> NSDictionary *dictionary = (NSDictionary *) [parser
> objectWithString:responseString error:nil];
> NSDictionary *user = (NSDictionary *) [dictionary valueForKey:@"user"];
> if([user valueForKey:@"screen_name"] != nil) {
> Tweet *tweet = [[Tweet alloc] init];
> [tweet setScreenName:[user valueForKey:@"screen_name"]];
> [tweet setLink:[user valueForKey:@"profile_image_url"]];
> [tweet setMessage:[dictionary valueForKey:@"text"]];
> //do something
> [tweet release];
> }
> }
>
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Any chance of annotations for user objects?
I know you guys have plenty on your plates, just curious if it was on the roadmap. :) Sample use case (one I particularly want): Tweetie on my phone and Tweetie on my laptop could easily stay synced about where in my tweet stream I have read to. Other features like saved searches and lists could easily have begun life as user annotations. Generally lots of client data (prefs, settings, state) could be stored where it belongs, in the cloud, making it less transient, easier to migrate/sync/import/share, etc. Really excited about annotations -- thanks! Josh -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Streaming API - weird data in JSON text
Unicode? http://json.org/ -josh 2010/4/14 Mad Euchre : > Can someone please tell me why some tweets have the following as the > text? > > "text":"\uc624\ub298 \uc2dc\uac00\ucd1d\uc561\uc774 $AAPL \uc740 > $208.0B \uc774\uace0 $GOOG \uc740 $177.2B \ub124\uc694. > \uadf8\ub3d9\uc548 \uc5c5\uce58\ub77d \ub4a4\uce58\ub77d\ud558\ub358 > \ub450 \ud68c\uc0ac\uc758 \uc2dc\uac00\ucd1d\uc561 \uacbd\uc7c1\uc740 > \uc544\uc774\ud328\ub4dc \ubc1c\ud45c\ub97c \uc804\ud6c4\ud574\uc11c > \uc560\ud50c \ucabd\uc73c\ub85c \uae30\uc6b0\ub294 \uac83 > \uac19\uc2b5\ub2c8\ub2e4. \ubb3c\ub860 \ud5a5\ud6c4\uc5d0 \uc5b4\ub5bb > \uac8c \ub420\uc9c... > > Thanks, > > Peter > -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi John (et al.), These emails from you are great -- they are exactly the sort of thoughtful, detailed, specific, technical emails that I would personally love to see accompany future announcements. I think they would prevent a fair amount of FUD. Thank you. I have one stupid question, if you don't mind, though. You refer in every email to "K". What, precisely, does K refer to? What are its units? (I think I know what it you mean by it, but I'd be interested to hear precisely.) Thanks, Josh On Sun, Apr 11, 2010 at 2:23 PM, John Kalucki wrote: > If you are writing a general purpose display app, I think, (but I am not at > all certain), that you can ignore this issue. Reasonable polling frequency > on modest velocity timelines will sometimes, but very rarely, miss a tweet. > Also, over time, we're doing things to make this better for everyone. Many > of our projects have the side-effect of reducing K, decreasing the already > low since_id failure odds even further. Some tweet pipeline changes when > live in the last few weeks that dramatically reduce the K distribution for > various user types. > > Since I don't know how the Last-Modified time exactly works, I'm going to > restate your response slightly: > > Assuming synchronized clocks (or solely the Twitter Clock, if exposed > properly via Last-Modified), given a poll at time t, the newest status is at > least t - n seconds old, and sufficient n, then even a naive since_id > algorithm will be effectively Exactly Once. Assuming that Twitter is running > normally. For a given poll, when the poll time and last update time delta > drops below this n second period, there's a non-zero loss risk. > > Just what is n? It is K expressed as time rather than as a discrete count. > For some timelines types, with some classes of users, K is as much as > perhaps 180 seconds. For others, K is less than 1 second. There's some > variability here that we should characterize more carefully internally and > then discuss publicly. I suspect there's a lot to be learned from this > exercise. > > Since_id really runs into trouble when any of the following are too great: > the polling frequency, the updating frequency, the roughly-sorted K value. > If you are polling often to reduce display latency, use the Streaming API. > If the timeline moves too fast to capture it all exactly, you should > reconsider your requirements or get a Commercial Data License for the > Streaming API. Does the user really need to see every Bieber at 3 Biebers > Per Second? How would they ever know if they missed 10^-5 of them in a blur? > If you need them all for analysis, consider calculating the confidence > interval given a sample proportion of 1 - 10^6 (6 9s) or so vs. a total > enumeration. Indistinguishable. If you need them for some other purpose, say > CRM, the Streaming API may be the answer. > > -John Kalucki > http://twitter.com/jkalucki > Infrastructure, Twitter Inc. > > > On Fri, Apr 9, 2010 at 2:28 PM, Brian Smith wrote: >> >> John, >> >> >> >> I am not polling. I am simply trying to implement a basic “refresh” >> feature like every desktop/mobile Twitter app has. Basically, I just want to >> let users scroll through their timelines, and be reasonably sure that I am >> presenting them with an accurate & complete view of the timeline, while >> using as little bandwidth as possible. >> >> >> >> When I said “10 seconds old”/“30 seconds old”/etc. I was referring to I >> was referring to the age at the time the page of tweets was generated. So, >> basically, if the tweet’s timestamp – the response’s Last-Modified time more >> than 10,000 ms (from what you said below), you are almost definitely getting >> At Least Once behavior if Twitter is operating normally, and you can use >> that information to get At Least Once behavior that emulates Exactly Once >> behavior with little (usually no) overhead. Is that a correct interpretation >> of what you were saying? >> >> >> >> Thanks, >> >> Brian >> >> >> >> >> >> From: twitter-development-talk@googlegroups.com >> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of John Kalucki >> Sent: Friday, April 09, 2010 3:31 PM >> To: twitter-development-talk@googlegroups.com >> Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are >> sequenced >> >> >> >> Your second paragraph doesn't quite make sense. The period between your >> next poll and the timestamp of the last status is irrelevant. The issue is >> solely the magnitude of K on the roughly sorted stream of events that are >> applied to the materialized timeline vector. As K varies, so do the odds, >> however infinitesimally small, that you will miss a tweet using the last >> status id returned. The period between your polls of the API does not affect >> this K. >> >> My recommendation is to ignore this issue in nearly every use case. If you >> are, however, polling high velocity timelines (including search queries) and >> attempting to approximate an Exactly Once QoS,
Re: [twitter-dev] Mobile view of twitter.com doesn't show "This person has protected their tweets" message
> Have a look at the new http://mobile.twitter.com. It looks awesome and > displays if profiles are protected. It does look awesome! The grammar freak in me feels compelled to point out that "Whats being said about..." should be "What's being said about..."; that is, it's missing the apostrophe in the contraction. Anyone at Twitter want to make a 1 (or 5) character fix? :) -josh -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
> So I think we need to allow Twitter some leeway here. I apologize if my tone came off badly; it was not intended. I've just had bumpy rides using timestamps for coordination in distributed systems (less cool ones than space flight), so this worried me a little. In the end, whatever Twitter decides to do, I'll work with. > As far as occasional glitches are concerned, we have those now. Every > so often, we still get Fail Whales, 5xx errors, DDos attacks, etc. The difference is that those errors are straightforwardly detectable on the client side and can be handled more or less gracefully. Minor, intermittent data issues (like the odd missing tweet) are less straightforward to detect, but still trigger support emails. :) -josh To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced
Hi Taylor (et al.), There are two reasons to think that, with the scheme you propose, tweet ids will not necessarily be monotonically increasing. Naveen hit the first: > It seems if two messages are posted at very close to same time, they may not > be sequential since the bottom bits will be randomly generated There is another: Time synchronization is hard to always get right (Einstein jokes aside). Clock skew happens for any number of reasons -- sometimes ntpd sends time backwards when network i/o gets really ugly, machine clocks wander, colos get out of sync, humans err, etc. These are rare events, but they do happen, and they can cause misalignment of clocks big enough for the odd tweet or two to fall through. Does missing the odd tweet or two matter? As for the tweet themselves: Probably not. But if it gets noticed, it causes users / developers to lose some amount of trust in their app / platform...and that matters a lot and can also generate a lot of annoying support emails. You wrote: > since_id will work as well as it does today as a result of this change. Is that assuming monotonically increasing tweet ids? If not, would you mind elaborating? Having a universal counter is untenable, but having occasional, undiagnosable, unreproducible glitches also sucks. :) Thinking out loud, perhaps there is some middle ground -- a way to have generally monotonically increasing ids globally, and guaranteed monotonically increasing ids along some useful dimension, such as per user (this doesn't play nicely e.g. w/ Cassandra, but it is still reasonably scalable by other means). Not sure whether that would help folks or not... -josh To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: [twitter-dev] Retweets
> I need to fix my retweets logic. Does anyone know someone (or some > recommended service) that retweets ad nauseum (via twitter's formal > retweet feature), or nearly so? I certainly wouldn't call it ad nauseum, but the esteemed @NickKristof retweets fairly regularly. -josh
Re: [twitter-dev] Inconsistent responses for particular users -- data for users/show, but Not found for statuses/friends
> http://api.twitter.com/1/statuses/friends.json?screen_name=johncow just
> worked fine for me. It might have been a temporary issue.
Confirmed -- works again for me. Looks like it was a temporary bump,
indeed. Thanks, Abraham.
-josh
> On Wed, Feb 24, 2010 at 07:02, Josh Bleecher Snyder
> wrote:
>>
>> Hi,
>>
>> I'm getting what look like inconsistent responses from the API for a
>> particular small handful of users. I'm sure I'm doing something
>> stupid, but I can't figure out what; any insight would be appreciated.
>> Here is a sample pair of problematic calls/responses:
>>
>> curl "http://api.twitter.com/1/users/show.json?screen_name=johncow";
>>
>> {"profile_background_image_url":"http://a3.twimg.com/profile_background_images/32506867/johncow1280x960.jpg","description":"Blogger,
>> SEO, PPC & Social Media Marketer, Software Developer, Mentor, Family
>> Man, Freak &
>> Christian!","friends_count":101,"profile_link_color":"ff","status":{"in_reply_to_status_id":null,"truncated":false,"created_at":"Wed
>> Feb 24 13:40:54 +
>>
>> 2010","in_reply_to_user_id":null,"source":"web","favorited":false,"in_reply_to_screen_name":null,"id":9575982473,"text":"ok,
>> enough of my ramble on
>>
>> http://bit.ly/974IBY"},"statuses_count":2280,"profile_background_tile":false,"created_at":"Thu
>> Jan 10 20:28:50 +
>>
>> 2008","favourites_count":0,"profile_background_color":"FF","contributors_enabled":false,"profile_image_url":"http://a1.twimg.com/profile_images/715616398/6531_138428637906_616647906_3253838_680520_n_normal.jpg","geo_enabled":false,"profile_sidebar_fill_color":"e0ff92","lang":"en","notifications":false,"screen_name":"johncow","following":false,"verified":false,"time_zone":"Eastern
>> Time (US &
>> Canada)","profile_sidebar_border_color":"87bc44","protected":false,"location":"Sault
>> Ste Marie, Canada","name":"Jason
>>
>> Katzenback","id":12084472,"utc_offset":-18000,"profile_text_color":"00","followers_count":13245,"url":"http://www.johncow.com"}
>>
>> So johncow exists, has friends, etc. But:
>>
>> curl "http://api.twitter.com/1/statuses/friends.json?screen_name=johncow";
>> {"request":"/1/statuses/friends.json?screen_name=johncow","error":"Not
>> found"}
>>
>> Any vision into what I've screwed up?
>>
>> Thanks,
>> Josh
>
>
>
> --
> Abraham Williams | Community Advocate | http://abrah.am
> Project | Out Loud | http://outloud.labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.
> Sent from Seattle, WA, United States
[twitter-dev] Inconsistent responses for particular users -- data for users/show, but Not found for statuses/friends
Hi,
I'm getting what look like inconsistent responses from the API for a
particular small handful of users. I'm sure I'm doing something
stupid, but I can't figure out what; any insight would be appreciated.
Here is a sample pair of problematic calls/responses:
curl "http://api.twitter.com/1/users/show.json?screen_name=johncow";
{"profile_background_image_url":"http://a3.twimg.com/profile_background_images/32506867/johncow1280x960.jpg","description":"Blogger,
SEO, PPC & Social Media Marketer, Software Developer, Mentor, Family
Man, Freak &
Christian!","friends_count":101,"profile_link_color":"ff","status":{"in_reply_to_status_id":null,"truncated":false,"created_at":"Wed
Feb 24 13:40:54 +
2010","in_reply_to_user_id":null,"source":"web","favorited":false,"in_reply_to_screen_name":null,"id":9575982473,"text":"ok,
enough of my ramble on
http://bit.ly/974IBY"},"statuses_count":2280,"profile_background_tile":false,"created_at":"Thu
Jan 10 20:28:50 +
2008","favourites_count":0,"profile_background_color":"FF","contributors_enabled":false,"profile_image_url":"http://a1.twimg.com/profile_images/715616398/6531_138428637906_616647906_3253838_680520_n_normal.jpg","geo_enabled":false,"profile_sidebar_fill_color":"e0ff92","lang":"en","notifications":false,"screen_name":"johncow","following":false,"verified":false,"time_zone":"Eastern
Time (US &
Canada)","profile_sidebar_border_color":"87bc44","protected":false,"location":"Sault
Ste Marie, Canada","name":"Jason
Katzenback","id":12084472,"utc_offset":-18000,"profile_text_color":"00","followers_count":13245,"url":"http://www.johncow.com"}
So johncow exists, has friends, etc. But:
curl "http://api.twitter.com/1/statuses/friends.json?screen_name=johncow";
{"request":"/1/statuses/friends.json?screen_name=johncow","error":"Not found"}
Any vision into what I've screwed up?
Thanks,
Josh
Re: [twitter-dev] Oauth using api.twitter.com vs twitter.com
Hey Josh, Good to see I reached you, albeit not through the channel I'd anticipated. :) I really think the issue is quite simple; sorry I haven't expressed it clearly enough. If you look at the source of the http://(api.)?twitter.com/oauth/authorize page, you'll see that the sign up link is a relative url: Sign up and Join the Conversation! And http://api.twitter.com/signup?oauth_token= yields a 404 but http://twitter.com/signup?oauth_token= does not. So either (1) one is only supposed to use twitter.com for oauth/authorize, or (2) Twitter ought to be using an absolute url to point to http://twitter.com/signup, or (3) http://api.twitter.com/signup oughtn't be a 404, but a signup page. All the same goes, mutatis mutandis, for the sign out page. Hope that clarifies the issue a little. Oh, and by the way, thanks for the awesome library. :) -josh On Thu, Dec 17, 2009 at 3:16 PM, Josh Roesslein wrote: > Sorry left off the link to the issue. > > [1] http://github.com/joshthecoder/tweepy/issues#issue/8 > > Josh > > On Thu, Dec 17, 2009 at 2:15 PM, Josh Roesslein wrote: >> Hey, >> >> Thanks for bringing this issue to my attention. I have opened an issue >> for it here [1]. >> I will look into this and see what I can do to help resolve it. Shiplu >> is probably on the right track >> about this being cookie related. Will post updates here and on the >> issue as I make progress. >> >> Thanks, >> >> Josh Roesslein >> Tweepy author >> >> On Thu, Dec 17, 2009 at 1:42 PM, shiplu wrote: >>> On Fri, Dec 18, 2009 at 2:22 AM, Josh Bleecher Snyder >>> wrote: >>>> Hi all, >>>> >>>> The tweepy twitter client uses api.twitter.com for the host for oauth >>>> calls: >>>> >>>> REQUEST_TOKEN_URL = 'http://api.twitter.com/oauth/request_token' >>>> AUTHORIZATION_URL = 'http://api.twitter.com/oauth/authorize' >>>> AUTHENTICATE_URL = 'http://api.twitter.com/oauth/authenticate' >>>> ACCESS_TOKEN_URL = 'http://api.twitter.com/oauth/access_token' >>>> >>>> I've found that this works, until the user tries to sign out or sign >>>> up during the authorization; if this happens, they get a 404. If, >>>> however, twitter.com is used as the host: >>> >>> >>> I think this happens due to cookie. People sign in twitter.com. not in >>> api.twitter.com. When a user already signed in, the cookie's domain is >>> twitter.com. >>> Now if you redirect to http://api.twitter.com/oauth/authorize, browser >>> wont load the cookie as its from twitter.com. It'll try to find >>> cookies from api.twitter.com. But there is no cookie. So you have to >>> sign in again I guess. >>> >>> Its better to use twitter.com instead of api.twitter.com when its one >>> of those 4 oauth urls. >>> >>> -- >>> Shiplu Mokaddim >>> My talks, http://talk.cmyweb.net >>> Follow me, http://twitter.com/shiplu >>> SUST Programmers, http://groups.google.com/group/p2psust >>> Innovation distinguishes bet ... ... (ask Steve Jobs the rest) >>> >> >
Re: [twitter-dev] Oauth using api.twitter.com vs twitter.com
Hey Shiplu, >> I've found that this works, until the user tries to sign out or sign >> up during the authorization; if this happens, they get a 404. If, >> however, twitter.com is used as the host: > > I think this happens due to cookie. People sign in twitter.com. not in > api.twitter.com. When a user already signed in, the cookie's domain is > twitter.com. Thanks for the suggestion. However, this is definitely url/host/routing related, not cookie related. (a) I can reproduce after clearing all cookies. (b) The cookie api.twitter.com sets has .twitter.com as its domain. (c) http://api.twitter.com/signup?oauth_token= yields a 404; http://twitter.com/signup?oauth_token= does not. (d) The issue is not that it doesn't remember the user, but rather that the "sign out" and "sign up" links on the oauth page are broken (lead to 404s). -josh
[twitter-dev] Oauth using api.twitter.com vs twitter.com
Hi all, The tweepy twitter client uses api.twitter.com for the host for oauth calls: REQUEST_TOKEN_URL = 'http://api.twitter.com/oauth/request_token' AUTHORIZATION_URL = 'http://api.twitter.com/oauth/authorize' AUTHENTICATE_URL = 'http://api.twitter.com/oauth/authenticate' ACCESS_TOKEN_URL = 'http://api.twitter.com/oauth/access_token' I've found that this works, until the user tries to sign out or sign up during the authorization; if this happens, they get a 404. If, however, twitter.com is used as the host: REQUEST_TOKEN_URL = 'http://twitter.com/oauth/request_token' AUTHORIZATION_URL = 'http://twitter.com/oauth/authorize' AUTHENTICATE_URL = 'http://twitter.com/oauth/authenticate' ACCESS_TOKEN_URL = 'http://twitter.com/oauth/access_token' then *everything*, including signout and signup, works. This also matches the instructions at http://twitter.com/oauth_clients/details/%d. However, it strikes me as odd that the oauth stuff half works at api.twitter.com. My question is: What is the bug? That the api.twitter.com oauth endpoints only partially work -- in which case tweepy is fine and I should file a bug with Twitter -- OR that the api.twitter.com oauth works at all -- in which case I should ping the author of tweepy and perhaps suggest to Twitter that they remove this partial functionality to prevent future confusion? Many thanks, Josh
Re: [twitter-dev] What exactly does the follow parameter to friendships/create do?
Thanks Zach and Josh. Sure enough, it was a stupid question. :) Definitely seems like adding more color to the docs would be a good idea. -josh On Sun, Dec 13, 2009 at 12:03 AM, Josh Roesslein wrote: > Hey Josh, > > Notifications when enable will cause tweets from the followed user to > be sent to the authenticated user's device. > See > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-notifications%C2%A0follow > for more details. > > Josh > > On Sat, Dec 12, 2009 at 7:37 PM, Josh Bleecher Snyder > wrote: >> Hi all, >> >> I'm sure this is a stupid question, but my Google kung fu is failing me. >> >> http://apiwiki.twitter.com/Twitter-REST-API-Method:-friendships%C2%A0create >> describes the parameter thus: >> >> * follow. Optional. Enable notifications for the target user in >> addition to becoming friends. >> >> What confuses me is: What are "notifications for the target user"? >> >> Thanks, >> Josh >> >
[twitter-dev] What exactly does the follow parameter to friendships/create do?
Hi all, I'm sure this is a stupid question, but my Google kung fu is failing me. http://apiwiki.twitter.com/Twitter-REST-API-Method:-friendships%C2%A0create describes the parameter thus: * follow. Optional. Enable notifications for the target user in addition to becoming friends. What confuses me is: What are "notifications for the target user"? Thanks, Josh
