[twitter-dev] New notification email extra headers
Hi guys, Thanks for creating the new twitter event notification emails (favs, retweets, mentions). Could I please request that "X-Twitteremailtype:" headers be included in those emails as well? DM emails already have: X-Twitteremailtype: direct_message and Follwer emails have: X-Twitteremailtype: is_following and if you are feeling generous, could I please request that each email type also gets something like a "X-Twittertext" header that contains the actual one-line text of the email's focus? It would be much simpler than trying to parse out the data from the plaintext/html parts of the body. for DMs it would be the DM text, for RT it would be the original tweet text, for Favs it would be the original tweet text, for Mentions it would be the tweet text from the reply-er, for Followers I'm not sure what it would be (maybe nothing). All other useful information is already included in the headers (sender/receiver usernames/ids). Adding the text would be s nice :) Thanks again, -Chad -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] push notification for iPhone app.
Hello. In 'Twittet for iPhone' and 'twtkr for iPhone', we can get a push notification by realtime when there is new DM or mention. (most of time) I also developed and released twitter app for iPhone - all4twit I would like to provide this function to my customers but I wasn't able to find an API. That's why my customer could receive a push notification only from the customer who is using same all4twit. Is it possible to recognize if there is new DM or mention for eah of all my ustomers? which API I could use? Please inform me. Thanks. Kelly Park. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Delivery Status Notification (Failure)
> > Hi, > > I have implemented twitter appllication in C#.net. I have used X-Auth > authentication. Ie, we have directly entered int twitter account, not > displayed twitter autherization pages. In that application I have displayed > home tweets, to displayed friends,followers, search, etc.. Could you please > explain mw, how to help u? > Regards, > George > > On Fri, Sep 3, 2010 at 12:18 PM, John SJ Anderson >wrote: > > > Specifically, what platform(s) are you targeting and what > > functionality do you look to add? > > > > > > On Thu, Sep 2, 2010 at 23:30, Georgooty varghese > > wrote: > > > Hi, > > > Which help u need. > > > Regards, > > > George > > > > > > On Fri, Sep 3, 2010 at 3:20 AM, Mike Morang > > wrote: > > >> > > >> I need a Twitter developer to add functionality to my approved Twitter > > >> app. > > >> Best Regards, > > >> Michael Morang > > >> Principal Consultant > > >> iPlus Marketing Corp. > > >> 714-594-7374 > > >> Website: iPlusMarketing.com > > >> Email: m...@iplusmarketing.com > > >> Follow me on Twitter: Twitter.com/iPlusMarketing > > >> Linkedin:http://www.linkedin.com/in/mikemorang > > >> Skype: GrowMe > > >> > > >> -- > > >> Twitter developer documentation and resources: > > http://dev.twitter.com/doc > > >> API updates via Twitter: http://twitter.com/twitterapi > > >> Issues/Enhancements Tracker: > > >> http://code.google.com/p/twitter-api/issues/list > > >> Change your membership to this group: > > >> http://groups.google.com/group/twitter-development-talk?hl=en > > > > > > -- > > > Twitter developer documentation and resources: > > http://dev.twitter.com/doc > > > API updates via Twitter: http://twitter.com/twitterapi > > > Issues/Enhancements Tracker: > > > http://code.google.com/p/twitter-api/issues/list > > > Change your membership to this group: > > > http://groups.google.com/group/twitter-development-talk?hl=en > > > > > > > -- > > Twitter developer documentation and resources: > http://dev.twitter.com/doc > > API updates via Twitter: http://twitter.com/twitterapi > > Issues/Enhancements Tracker: > > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Tweet Button callback or notification
The Tweet button is great! Right now we're using it as a contest device. Users tweet about a product they like using the Tweet Button and they are automatically entered to win the item they tweeted about, it's very cool. However we're having to use some pretty difficult ways of grabbing all of the tweets to select a random winner. Anyone know if there are plans to add a notification URL so we can get some data on how often the TB is used, on what pages, etc ? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Re: Notification on Twitter when viewing Website
api.twitter.com On 13 juil, 11:10, "Joep v. Mourick" wrote: > Hi All, > > I'm currently working on a website for a event. On the homepage I've > installed a twitter application witch shows my tweets about the event. > > I would like to add a button by witch the visitors can tweet that > they're visiting our website. I know that it is possible in some music > app's. > > Does anybody know how to implement this in Joomla CMS? > > Cheers, > > Joep
[twitter-dev] Notification on Twitter when viewing Website
Hi All, I'm currently working on a website for a event. On the homepage I've installed a twitter application witch shows my tweets about the event. I would like to add a button by witch the visitors can tweet that they're visiting our website. I know that it is possible in some music app's. Does anybody know how to implement this in Joomla CMS? Cheers, Joep
[twitter-dev] Re: Whitelisting Notification
That's fair. Thank you kindly! Regards, Luke On Oct 28, 10:43 pm, Chad Etzel wrote: > Hello, > > The queue is being worked on, hopefully everything will be cleared out > tomorrow. If you haven't gotten a response by tomorrow night, please > let me know. > > -Chad > > On Wed, Oct 28, 2009 at 11:34 PM, Atul Kulkarni > wrote: > > It took me a little longer than a week. Be patient... the form you filled is > > the only thing I know one can do. > > > You could search the archives of a few weeks back for a thread where Chad > > answered this question. > > > Hope this helps. > > > Regards, > > Atul. > > > On Wed, Oct 28, 2009 at 1:47 PM, Luke Sneeringer > > wrote: > > >> Good afternoon, > >> I have a question regarding whitelisting. I am a developer looking to > >> produce material against the Twitter API (blah blah), and I recently > >> requested whitelisting. The form says it takes 72 hours. So far, so > >> good. > > >> That was a week ago, and I've heard nothing. I haven't been rejected > >> per sé (that I know of), but my IP is still very much rate-limited to > >> 150 requests per hour, and I've heard nothing. I haven't gotten an > >> email informing me in either direction. I don't want to fill out the > >> form again as I don't really want to even further overload some poor > >> fellow. > > >> Does anyone know what the story is here? Do they take longer than 72 > >> hours now? It's fine if they do. I just don't want to keep filling out > >> requests if in fact there's just a longer queue, but I also don't want > >> to sit and wait only to find out in a month that I was supposed to do > >> some arbitrary action I didn't notice. > > >> Thanks, > >> Luke > > > -- > > Regards, > > Atul Kulkarni > >www.d.umn.edu/~kulka053
[twitter-dev] Re: Whitelisting Notification
Hello, The queue is being worked on, hopefully everything will be cleared out tomorrow. If you haven't gotten a response by tomorrow night, please let me know. -Chad On Wed, Oct 28, 2009 at 11:34 PM, Atul Kulkarni wrote: > It took me a little longer than a week. Be patient... the form you filled is > the only thing I know one can do. > > You could search the archives of a few weeks back for a thread where Chad > answered this question. > > Hope this helps. > > Regards, > Atul. > > On Wed, Oct 28, 2009 at 1:47 PM, Luke Sneeringer > wrote: >> >> Good afternoon, >> I have a question regarding whitelisting. I am a developer looking to >> produce material against the Twitter API (blah blah), and I recently >> requested whitelisting. The form says it takes 72 hours. So far, so >> good. >> >> That was a week ago, and I've heard nothing. I haven't been rejected >> per sé (that I know of), but my IP is still very much rate-limited to >> 150 requests per hour, and I've heard nothing. I haven't gotten an >> email informing me in either direction. I don't want to fill out the >> form again as I don't really want to even further overload some poor >> fellow. >> >> Does anyone know what the story is here? Do they take longer than 72 >> hours now? It's fine if they do. I just don't want to keep filling out >> requests if in fact there's just a longer queue, but I also don't want >> to sit and wait only to find out in a month that I was supposed to do >> some arbitrary action I didn't notice. >> >> Thanks, >> Luke > > > > -- > Regards, > Atul Kulkarni > www.d.umn.edu/~kulka053 >
[twitter-dev] Re: Whitelisting Notification
It took me a little longer than a week. Be patient... the form you filled is the only thing I know one can do. You could search the archives of a few weeks back for a thread where Chad answered this question. Hope this helps. Regards, Atul. On Wed, Oct 28, 2009 at 1:47 PM, Luke Sneeringer wrote: > > Good afternoon, > I have a question regarding whitelisting. I am a developer looking to > produce material against the Twitter API (blah blah), and I recently > requested whitelisting. The form says it takes 72 hours. So far, so > good. > > That was a week ago, and I've heard nothing. I haven't been rejected > per sé (that I know of), but my IP is still very much rate-limited to > 150 requests per hour, and I've heard nothing. I haven't gotten an > email informing me in either direction. I don't want to fill out the > form again as I don't really want to even further overload some poor > fellow. > > Does anyone know what the story is here? Do they take longer than 72 > hours now? It's fine if they do. I just don't want to keep filling out > requests if in fact there's just a longer queue, but I also don't want > to sit and wait only to find out in a month that I was supposed to do > some arbitrary action I didn't notice. > > Thanks, > Luke > -- Regards, Atul Kulkarni www.d.umn.edu/~kulka053
[twitter-dev] Whitelisting Notification
Good afternoon, I have a question regarding whitelisting. I am a developer looking to produce material against the Twitter API (blah blah), and I recently requested whitelisting. The form says it takes 72 hours. So far, so good. That was a week ago, and I've heard nothing. I haven't been rejected per sé (that I know of), but my IP is still very much rate-limited to 150 requests per hour, and I've heard nothing. I haven't gotten an email informing me in either direction. I don't want to fill out the form again as I don't really want to even further overload some poor fellow. Does anyone know what the story is here? Do they take longer than 72 hours now? It's fine if they do. I just don't want to keep filling out requests if in fact there's just a longer queue, but I also don't want to sit and wait only to find out in a month that I was supposed to do some arbitrary action I didn't notice. Thanks, Luke
[twitter-dev] Re: large user base push notification solutions?
Great ideas. thanks a lot. Based on your data: 40,000 users, pull every 15 minutes, that means 44.5 requests/ second. Do you pull the data for everyone , or are there any short cuts that we can save server load? Also, did you do DMs as well? if so then you will need to deal 90 requests/second. Can a single VPS do that? which VPS provider? I want to buy that VPS :) On Aug 21, 8:28 pm, Paul Kinlan wrote: > When I developed Twe2, here are some of the things I have learnt > > - 2 minute delay is pretty short - users don't even notice it that much - > at one point on Twe2 we changed it to a 15 minute delay an no one really > complained. If users are getting pushed notifications they are normally > away from a main terminal and thus are not watching twitter through > TweetDeck; in short you don't need realtime to be that realtime > - Also 99.99% of people don't get that many notifications a day, polling > too often is a waste of time. > - We supported about 40,000 users off 1 small VPS. > - To get DM's you will need to use the users credentials (oauth or > otherwise), a 2 minute interval means that you will use 30 of the users > requests per hour (this might have changed) and as such they might get > annoyed. > - 500,000 users is pretty optimistic I wouldn't even worry about that > scale just yet, just get your stuff working for now. > - User since_id everywhere you can. > - We launched with the ability to have quiet periods, that is no > notifications while I am sleeping - people will thank you for this. > > Based on new developments of Twitter you can use something like follow, > shadow and birddog - it offers a migration plan too, start with follow to > get all the tweets from a user and to a user (200 users is good to test > your API works), then when you launch request twitter to allow you to use > shadow (50,000 users is a lot and will probably suit your app for a long > time). Then as soon as you see a tweet on the stream you know it is for > some of your users and you can fire it straight to them. the only issue is > that these API's only get proper replies and not mentions. > > Currently none of the Streaming API's will help you for DM's (AFAIK). > > Paul Kinlan,http://www.Twollo.com > > 2009/8/21 ke...@nibirutech.com > > > > > > > Hi > > > I am a developer , trying to figure out a way to develop a push > > notification solution for iPhone users. > > > The easy way to do the push work, is to have a cron-job to check > > users' new mentions and DMs. It should work for small number of > > users. What if we have a large user base, say , 500, 000 users at > > least? How can we use a proper solution to get a 2-minutes delay push > > for any user's mentions and DMs? (we can't afford the server cost for > > half million requests every 2 minutes) > > > I know there are a few Twitter push clients for iPhone , but none of > > them can work on a scaled user base, am I right? > > > Is there a twitter tech support here? could you please give some > > suggestions?
[twitter-dev] Re: large user base push notification solutions?
Apple push notification for iPhone works when the app is closed. In that case the iPhone client is not able to pull data. Meanwhile users want any mentions or DMs to pushed to them when the iPhone client is closed. So we must use a server to check DM & Mentions for users. On Aug 21, 8:10 pm, Andrew Badera wrote: > If you're already talking about a 2-minute delay, then why "push" and > not "pull" ?? Polling clients will give you greater scalability with > that range of latency easily achievable for little investment.Pushis > meant for immediate notifications. Truepushto 500k+ clients is > costly -- but you don't need millisecond latency here. Pull is much, > much cheaper. > > ∞ Andy Badera > ∞ This email is: [ ] bloggable [x] ask first [ ] private > ∞ Google me:http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) > > > > On Fri, Aug 21, 2009 at 8:07 AM, Dewald Pretorius wrote: > > > In addition, your database will have to cope with 8,300 writes per > > second. And then you need to take into account the latency of the > > ApplePushNotificationservice. > > > Dewald > > > On Aug 21, 8:57 am, Dewald Pretorius wrote: > >> On Aug 21, 12:06 am, "ke...@nibirutech.com" > >> wrote: > > >> > What if we have a large user base, say , 500, 000 users at > >> > least? How can we use a proper solution to get a 2-minutes delaypush > >> > for any user's mentions and DMs? (we can't afford the server cost for > >> > half million requests every 2 minutes) > > >> You are actually talking about one million API calls every 2 minutes > >> (1 for mentions, one for DMs). > > >> That's 8,300 API calls per second. > > >> My rough estimate is that you are going to need around 200 servers to > >> cope with that workload. > > >> Dewald
[twitter-dev] Re: large user base push notification solutions?
When I developed Twe2, here are some of the things I have learnt - 2 minute delay is pretty short - users don't even notice it that much - at one point on Twe2 we changed it to a 15 minute delay an no one really complained. If users are getting pushed notifications they are normally away from a main terminal and thus are not watching twitter through TweetDeck; in short you don't need realtime to be that realtime - Also 99.99% of people don't get that many notifications a day, polling too often is a waste of time. - We supported about 40,000 users off 1 small VPS. - To get DM's you will need to use the users credentials (oauth or otherwise), a 2 minute interval means that you will use 30 of the users requests per hour (this might have changed) and as such they might get annoyed. - 500,000 users is pretty optimistic I wouldn't even worry about that scale just yet, just get your stuff working for now. - User since_id everywhere you can. - We launched with the ability to have quiet periods, that is no notifications while I am sleeping - people will thank you for this. Based on new developments of Twitter you can use something like follow, shadow and birddog - it offers a migration plan too, start with follow to get all the tweets from a user and to a user (200 users is good to test your API works), then when you launch request twitter to allow you to use shadow (50,000 users is a lot and will probably suit your app for a long time). Then as soon as you see a tweet on the stream you know it is for some of your users and you can fire it straight to them. the only issue is that these API's only get proper replies and not mentions. Currently none of the Streaming API's will help you for DM's (AFAIK). Paul Kinlan, http://www.Twollo.com 2009/8/21 ke...@nibirutech.com > > Hi > > I am a developer , trying to figure out a way to develop a push > notification solution for iPhone users. > > The easy way to do the push work, is to have a cron-job to check > users' new mentions and DMs. It should work for small number of > users. What if we have a large user base, say , 500, 000 users at > least? How can we use a proper solution to get a 2-minutes delay push > for any user's mentions and DMs? (we can't afford the server cost for > half million requests every 2 minutes) > > I know there are a few Twitter push clients for iPhone , but none of > them can work on a scaled user base, am I right? > > Is there a twitter tech support here? could you please give some > suggestions? >
[twitter-dev] Re: large user base push notification solutions?
On Aug 21, 12:06 am, "ke...@nibirutech.com" wrote: > What if we have a large user base, say , 500, 000 users at > least? How can we use a proper solution to get a 2-minutes delay push > for any user's mentions and DMs? (we can't afford the server cost for > half million requests every 2 minutes) You are actually talking about one million API calls every 2 minutes (1 for mentions, one for DMs). That's 8,300 API calls per second. My rough estimate is that you are going to need around 200 servers to cope with that workload. Dewald
[twitter-dev] Re: large user base push notification solutions?
If you're already talking about a 2-minute delay, then why "push" and not "pull" ?? Polling clients will give you greater scalability with that range of latency easily achievable for little investment. Push is meant for immediate notifications. True push to 500k+ clients is costly -- but you don't need millisecond latency here. Pull is much, much cheaper. ∞ Andy Badera ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera) On Fri, Aug 21, 2009 at 8:07 AM, Dewald Pretorius wrote: > > In addition, your database will have to cope with 8,300 writes per > second. And then you need to take into account the latency of the > Apple Push Notification service. > > Dewald > > On Aug 21, 8:57 am, Dewald Pretorius wrote: >> On Aug 21, 12:06 am, "ke...@nibirutech.com" >> wrote: >> >> > What if we have a large user base, say , 500, 000 users at >> > least? How can we use a proper solution to get a 2-minutes delay push >> > for any user's mentions and DMs? (we can't afford the server cost for >> > half million requests every 2 minutes) >> >> You are actually talking about one million API calls every 2 minutes >> (1 for mentions, one for DMs). >> >> That's 8,300 API calls per second. >> >> My rough estimate is that you are going to need around 200 servers to >> cope with that workload. >> >> Dewald >
[twitter-dev] Re: large user base push notification solutions?
In addition, your database will have to cope with 8,300 writes per second. And then you need to take into account the latency of the Apple Push Notification service. Dewald On Aug 21, 8:57 am, Dewald Pretorius wrote: > On Aug 21, 12:06 am, "ke...@nibirutech.com" > wrote: > > > What if we have a large user base, say , 500, 000 users at > > least? How can we use a proper solution to get a 2-minutes delay push > > for any user's mentions and DMs? (we can't afford the server cost for > > half million requests every 2 minutes) > > You are actually talking about one million API calls every 2 minutes > (1 for mentions, one for DMs). > > That's 8,300 API calls per second. > > My rough estimate is that you are going to need around 200 servers to > cope with that workload. > > Dewald
[twitter-dev] large user base push notification solutions?
Hi I am a developer , trying to figure out a way to develop a push notification solution for iPhone users. The easy way to do the push work, is to have a cron-job to check users' new mentions and DMs. It should work for small number of users. What if we have a large user base, say , 500, 000 users at least? How can we use a proper solution to get a 2-minutes delay push for any user's mentions and DMs? (we can't afford the server cost for half million requests every 2 minutes) I know there are a few Twitter push clients for iPhone , but none of them can work on a scaled user base, am I right? Is there a twitter tech support here? could you please give some suggestions?
[twitter-dev] Re: Deprecation of following and notification elements
Or, as I think slightly more clearly, perhaps this is an example of the inconsistency discussed in the OP. Sorry for the noise if that's the case. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On May 27, 11:50 am, Ed Finkler wrote: > Has this been implemented? I'm getting results that seem to indicate > so. Example: > > > curl > > "http://twitter.com/friendships/exists.json?user_a=spaztest&user_b=fun..."; > true > > curl > > "http://twitter.com/friendships/exists.json?user_a=funkatron&user_b=sp..."; > > true > > so those users are following each other. However, user info returned > in an authenticated request shows following:0 (that's the integer > "zero") > > > curl -k -u funkatron:##https://twitter.com/users/spaztest.json| > > prettyjson > > [...] > "following":0, > [...] > > > curl -k -u spaztest:perlsuckshttps://twitter.com/users/funkatron.json| > > prettyjson > > [...] > "following":0, > [...] > > I believe that "following" is supposed to indicate of the > authenticating user is following the requested user, but even if it's > the other way around, it seems wrong. Am I missing something, though? > > -- > Ed Finklerhttp://funkatron.com > Twitter:@funkatron > AIM: funka7ron > ICQ: 3922133 > XMPP:funkat...@gmail.com > > On May 11, 5:18 pm, Doug Williams wrote: > > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The > > defects report that methods returning user objects (see users/show for an > > example [3]) are returning incorrect or invalid values for the > > element. > > > The fix for this inconsistency is in fact non trivial [4]. The problem lies > > within the interaction of the application logic, caching layer and database > > design. The persistent data behind and values are > > separate from the user data in our architecture, so to keep these elements > > valid in cache alongside user objects adds a large amount of complexity. > > > Developers made it obvious that these data are a priority and we want to > > ensure they available. We also want to guarantee they are accurate and that > > performance remains good. Given the problems explained above, we are going > > to be making a number of changes to the API so that you can rely on the > > or data. > > > Deprecations: > > The following elements are to be removed from all returned user objects > > returned by the API: > > > 1) > > 2) > > > This deprecation will not occur until we finish the following: > > > Additions: > > To continue to provide access to this data we will be creating a new method: > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > will use a method similar to that described in this issue to deliver > > , , and (in the case of > > protected users) data with a single call. > > > We realize this change will cause an increase in API usage for some > > applications. Therefore we are going to increase the default API rate limit > > across the board. This should help absorb some of the costs for applications > > attempting to do interesting things with social graph data. The number will > > be somewhere between 101 and 200 calls but we still need to look at growth > > projections and current hardware capacity before settling on a definite > > number. > > > We plan to begin work on this relatively soon with the fix coming in a few > > weeks. We do not have a planned ship date at this time but will communicate > > specifics with developers as they are determined. We anticipate the new > > number of calls and a documented schema for the new method will be made > > available before the new method ships. Please watch this thread and > > @twitterapi for the incremental details. > > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > > Thanks, > > Doug > > -- > > > Doug Williams > > Twitter Platform Supporthttp://twitter.com/dougw > >
[twitter-dev] Re: Deprecation of following and notification elements
Has this been implemented? I'm getting results that seem to indicate so. Example: > curl > "http://twitter.com/friendships/exists.json?user_a=spaztest&user_b=funkatron"; true > curl > "http://twitter.com/friendships/exists.json?user_a=funkatron&user_b=spaztest"; true so those users are following each other. However, user info returned in an authenticated request shows following:0 (that's the integer "zero") > curl -k -u funkatron:## https://twitter.com/users/spaztest.json | > prettyjson [...] "following":0, [...] > curl -k -u spaztest:perlsucks https://twitter.com/users/funkatron.json | > prettyjson [...] "following":0, [...] I believe that "following" is supposed to indicate of the authenticating user is following the requested user, but even if it's the other way around, it seems wrong. Am I missing something, though? -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On May 11, 5:18 pm, Doug Williams wrote: > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The > defects report that methods returning user objects (see users/show for an > example [3]) are returning incorrect or invalid values for the > element. > > The fix for this inconsistency is in fact non trivial [4]. The problem lies > within the interaction of the application logic, caching layer and database > design. The persistent data behind and values are > separate from the user data in our architecture, so to keep these elements > valid in cache alongside user objects adds a large amount of complexity. > > Developers made it obvious that these data are a priority and we want to > ensure they available. We also want to guarantee they are accurate and that > performance remains good. Given the problems explained above, we are going > to be making a number of changes to the API so that you can rely on the > or data. > > Deprecations: > The following elements are to be removed from all returned user objects > returned by the API: > > 1) > 2) > > This deprecation will not occur until we finish the following: > > Additions: > To continue to provide access to this data we will be creating a new method: > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > will use a method similar to that described in this issue to deliver > , , and (in the case of > protected users) data with a single call. > > We realize this change will cause an increase in API usage for some > applications. Therefore we are going to increase the default API rate limit > across the board. This should help absorb some of the costs for applications > attempting to do interesting things with social graph data. The number will > be somewhere between 101 and 200 calls but we still need to look at growth > projections and current hardware capacity before settling on a definite > number. > > We plan to begin work on this relatively soon with the fix coming in a few > weeks. We do not have a planned ship date at this time but will communicate > specifics with developers as they are determined. We anticipate the new > number of calls and a documented schema for the new method will be made > available before the new method ships. Please watch this thread and > @twitterapi for the incremental details. > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of following and notification elements
Can I suggest that you add that this value is unused and will be removed to the API documentation. I have spent quite a while writing code which I found out wasnt working cos the values are random and unreliable and then searched around to eventually find this post and find out it is a problem that wont be fixed. Thanks.
[twitter-dev] Re: Deprecation of following and notification elements
Doug, I appreciate your taking the time to respond to my criticism. I understand where you're coming from and if I was you I would probably take the same view. I'm slow to go down the proxy route because this would require server resources and, like most Twitter clients, my app is non-commercial. Another issue with use of a proxy is that Enterprise-managed mobile devices (e.g. BlackBerry devices that use a BES) are often restricted to a white list of HTTP endpoints. It is much easier to persuade an admin to allow twitter.com:80 than proxy.dodgy.com:80. Hey, here's a cheeky suggestion for Twitter: provide free VM-based hosting for mobile proxies... Regards, Dave. On May 12, 1:14 am, Doug Williams wrote: > David, > As with any solution there are compromises (the normal big three are time, > resources, quality of service) and while this change may make your > particular use of the API more difficult, it is not only important but also > necessary given our architecture and growth. The API provides Twitter data > in a format that is consistent with our strengths. It is up to the consuming > application to make the data we freely provide useful in its independent > context. This decoupling of data and application allows us to focus on data > delivery while the developer attends to user experience. We aim to maximize > performance for board array of use-cases and while at the same time > minimizing operational and maintenance costs. > > There are many very successful mobile applications that run a proxy to get > around the resource/time trade-off that this deprecation creates. If you are > mobile heavy, it is suggested you do the same. A proxy is highly recommended > for iPhone apps because it insulates the application changes in the Twitter > API with the App Store acceptance delay. > > If anyone has an open source Twitter API proxy, please start another thread > so mobile developers like David do not have to reinvent the wheel. In fact, > there should be a FOSS project for mobile devs to rely on -- I've got a > couple ideas to contribute. Again, please start a thread (and link back > here) if you have code or interest in starting a proxy project. > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Supporthttp://twitter.com/dougw > > On Mon, May 11, 2009 at 4:38 PM, Dave Mc wrote: > > > To be blunt this is very unsatisfactory. Once again you guys are not > > being at all cognisant of the requirements of mobile Twitter client > > apps. These face much bigger problems than just the rate limit. They > > are constrained by physical limitations such as battery life, latency > > and bandwidth. And they also have to take account of carrier data > > charges. Every time something in your API requires an additional > > method call you are making life difficult for us mobile app developers > > who are trying to deliver a quality Twitter client to our users (who > > are also your users!). > > > What annoys me too is that whenever a mobile-specific issue is raised > > your stock response is "handle that in a proxy". Guys, that's just not > > good enough. The World is going mobile and the continuing development > > of your API needs to take account of this. > > > Very unhappy about this! > > > On May 11, 10:18 pm, Doug Williams wrote: > > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. > > The > > > defects report that methods returning user objects (see users/show for an > > > example [3]) are returning incorrect or invalid values for the > > > > > element. > > > > The fix for this inconsistency is in fact non trivial [4]. The problem > > lies > > > within the interaction of the application logic, caching layer and > > database > > > design. The persistent data behind and values > > are > > > separate from the user data in our architecture, so to keep these > > elements > > > valid in cache alongside user objects adds a large amount of complexity. > > > > Developers made it obvious that these data are a priority and we want to > > > ensure they available. We also want to guarantee they are accurate and > > that > > > performance remains good. Given the problems explained above, we are > > going > > > to be making a number of changes to the API so that you can rely on the > > > or data. > > > > Deprecations: > > > The following elements are to be removed from all returned user objects > > > returned by the API: > > > > 1) > > > 2) > > > > This deprecation will not occur until we finish the following: > > > > Additions: > > > To continue to provide access to this data we will be creating a new > > method: > > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > > will use a method similar to that described in this issue to deliver > > > , , and (in the case of > > > protected users) data with a single call. > > > > We realize this change will cause an increase in API usage for some > > > applications. Therefore we are going to increase the def
[twitter-dev] Re: Deprecation of following and notification elements
Doug: At least we are not expecting this bug to be fixed. So we will have to go with a peripheral API call. I would have really love to get this in the same stanza however because, as Dave said very *loudly*, that makes life much easier for us mobile developers. Now we will have to wrap this in a soft transactional layer to ensure we get all the proper data for a user. But if this is you final answer than we must go with that... Martin - www.wherecloud.com On May 11, 8:14 pm, Doug Williams wrote: > David, > As with any solution there are compromises (the normal big three are time, > resources, quality of service) and while this change may make your > particular use of the API more difficult, it is not only important but also > necessary given our architecture and growth. The API provides Twitter data > in a format that is consistent with our strengths. It is up to the consuming > application to make the data we freely provide useful in its independent > context. This decoupling of data and application allows us to focus on data > delivery while the developer attends to user experience. We aim to maximize > performance for board array of use-cases and while at the same time > minimizing operational and maintenance costs. > > There are many very successful mobile applications that run a proxy to get > around the resource/time trade-off that this deprecation creates. If you are > mobile heavy, it is suggested you do the same. A proxy is highly recommended > for iPhone apps because it insulates the application changes in the Twitter > API with the App Store acceptance delay. > > If anyone has an open source Twitter API proxy, please start another thread > so mobile developers like David do not have to reinvent the wheel. In fact, > there should be a FOSS project for mobile devs to rely on -- I've got a > couple ideas to contribute. Again, please start a thread (and link back > here) if you have code or interest in starting a proxy project. > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Supporthttp://twitter.com/dougw > > > > On Mon, May 11, 2009 at 4:38 PM, Dave Mc wrote: > > > To be blunt this is very unsatisfactory. Once again you guys are not > > being at all cognisant of the requirements of mobile Twitter client > > apps. These face much bigger problems than just the rate limit. They > > are constrained by physical limitations such as battery life, latency > > and bandwidth. And they also have to take account of carrier data > > charges. Every time something in your API requires an additional > > method call you are making life difficult for us mobile app developers > > who are trying to deliver a quality Twitter client to our users (who > > are also your users!). > > > What annoys me too is that whenever a mobile-specific issue is raised > > your stock response is "handle that in a proxy". Guys, that's just not > > good enough. The World is going mobile and the continuing development > > of your API needs to take account of this. > > > Very unhappy about this! > > > On May 11, 10:18 pm, Doug Williams wrote: > > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. > > The > > > defects report that methods returning user objects (see users/show for an > > > example [3]) are returning incorrect or invalid values for the > > > > > element. > > > > The fix for this inconsistency is in fact non trivial [4]. The problem > > lies > > > within the interaction of the application logic, caching layer and > > database > > > design. The persistent data behind and values > > are > > > separate from the user data in our architecture, so to keep these > > elements > > > valid in cache alongside user objects adds a large amount of complexity. > > > > Developers made it obvious that these data are a priority and we want to > > > ensure they available. We also want to guarantee they are accurate and > > that > > > performance remains good. Given the problems explained above, we are > > going > > > to be making a number of changes to the API so that you can rely on the > > > or data. > > > > Deprecations: > > > The following elements are to be removed from all returned user objects > > > returned by the API: > > > > 1) > > > 2) > > > > This deprecation will not occur until we finish the following: > > > > Additions: > > > To continue to provide access to this data we will be creating a new > > method: > > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > > will use a method similar to that described in this issue to deliver > > > , , and (in the case of > > > protected users) data with a single call. > > > > We realize this change will cause an increase in API usage for some > > > applications. Therefore we are going to increase the default API rate > > limit > > > across the board. This should help absorb some of the costs for > > applications > > > attempting to do interesting things with social graph data. The number > > will > > > be s
[twitter-dev] Re: Deprecation of following and notification elements
Something to keep in mind is that when switching from a computer to a mobile device you are losing power/features for mobility. You have to expect the same loss in functionality. On Mon, May 11, 2009 at 18:38, Dave Mc wrote: > > To be blunt this is very unsatisfactory. Once again you guys are not > being at all cognisant of the requirements of mobile Twitter client > apps. These face much bigger problems than just the rate limit. They > are constrained by physical limitations such as battery life, latency > and bandwidth. And they also have to take account of carrier data > charges. Every time something in your API requires an additional > method call you are making life difficult for us mobile app developers > who are trying to deliver a quality Twitter client to our users (who > are also your users!). > > What annoys me too is that whenever a mobile-specific issue is raised > your stock response is "handle that in a proxy". Guys, that's just not > good enough. The World is going mobile and the continuing development > of your API needs to take account of this. > > Very unhappy about this! > > On May 11, 10:18 pm, Doug Williams wrote: > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. > The > > defects report that methods returning user objects (see users/show for an > > example [3]) are returning incorrect or invalid values for the > > > element. > > > > The fix for this inconsistency is in fact non trivial [4]. The problem > lies > > within the interaction of the application logic, caching layer and > database > > design. The persistent data behind and values > are > > separate from the user data in our architecture, so to keep these > elements > > valid in cache alongside user objects adds a large amount of complexity. > > > > Developers made it obvious that these data are a priority and we want to > > ensure they available. We also want to guarantee they are accurate and > that > > performance remains good. Given the problems explained above, we are > going > > to be making a number of changes to the API so that you can rely on the > > or data. > > > > Deprecations: > > The following elements are to be removed from all returned user objects > > returned by the API: > > > > 1) > > 2) > > > > This deprecation will not occur until we finish the following: > > > > Additions: > > To continue to provide access to this data we will be creating a new > method: > > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > will use a method similar to that described in this issue to deliver > > , , and (in the case of > > protected users) data with a single call. > > > > We realize this change will cause an increase in API usage for some > > applications. Therefore we are going to increase the default API rate > limit > > across the board. This should help absorb some of the costs for > applications > > attempting to do interesting things with social graph data. The number > will > > be somewhere between 101 and 200 calls but we still need to look at > growth > > projections and current hardware capacity before settling on a definite > > number. > > > > We plan to begin work on this relatively soon with the fix coming in a > few > > weeks. We do not have a planned ship date at this time but will > communicate > > specifics with developers as they are determined. We anticipate the new > > number of calls and a documented schema for the new method will be made > > available before the new method ships. Please watch this thread and > > @twitterapi for the incremental details. > > > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > > > Thanks, > > Doug > > -- > > > > Doug Williams > > Twitter Platform Supporthttp://twitter.com/dougw > -- Abraham Williams | http://the.hackerconundrum.com Hacker | http://abrah.am | http://twitter.com/abraham Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Deprecation of following and notification elements
David, As with any solution there are compromises (the normal big three are time, resources, quality of service) and while this change may make your particular use of the API more difficult, it is not only important but also necessary given our architecture and growth. The API provides Twitter data in a format that is consistent with our strengths. It is up to the consuming application to make the data we freely provide useful in its independent context. This decoupling of data and application allows us to focus on data delivery while the developer attends to user experience. We aim to maximize performance for board array of use-cases and while at the same time minimizing operational and maintenance costs. There are many very successful mobile applications that run a proxy to get around the resource/time trade-off that this deprecation creates. If you are mobile heavy, it is suggested you do the same. A proxy is highly recommended for iPhone apps because it insulates the application changes in the Twitter API with the App Store acceptance delay. If anyone has an open source Twitter API proxy, please start another thread so mobile developers like David do not have to reinvent the wheel. In fact, there should be a FOSS project for mobile devs to rely on -- I've got a couple ideas to contribute. Again, please start a thread (and link back here) if you have code or interest in starting a proxy project. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Mon, May 11, 2009 at 4:38 PM, Dave Mc wrote: > > To be blunt this is very unsatisfactory. Once again you guys are not > being at all cognisant of the requirements of mobile Twitter client > apps. These face much bigger problems than just the rate limit. They > are constrained by physical limitations such as battery life, latency > and bandwidth. And they also have to take account of carrier data > charges. Every time something in your API requires an additional > method call you are making life difficult for us mobile app developers > who are trying to deliver a quality Twitter client to our users (who > are also your users!). > > What annoys me too is that whenever a mobile-specific issue is raised > your stock response is "handle that in a proxy". Guys, that's just not > good enough. The World is going mobile and the continuing development > of your API needs to take account of this. > > Very unhappy about this! > > On May 11, 10:18 pm, Doug Williams wrote: > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. > The > > defects report that methods returning user objects (see users/show for an > > example [3]) are returning incorrect or invalid values for the > > > element. > > > > The fix for this inconsistency is in fact non trivial [4]. The problem > lies > > within the interaction of the application logic, caching layer and > database > > design. The persistent data behind and values > are > > separate from the user data in our architecture, so to keep these > elements > > valid in cache alongside user objects adds a large amount of complexity. > > > > Developers made it obvious that these data are a priority and we want to > > ensure they available. We also want to guarantee they are accurate and > that > > performance remains good. Given the problems explained above, we are > going > > to be making a number of changes to the API so that you can rely on the > > or data. > > > > Deprecations: > > The following elements are to be removed from all returned user objects > > returned by the API: > > > > 1) > > 2) > > > > This deprecation will not occur until we finish the following: > > > > Additions: > > To continue to provide access to this data we will be creating a new > method: > > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > will use a method similar to that described in this issue to deliver > > , , and (in the case of > > protected users) data with a single call. > > > > We realize this change will cause an increase in API usage for some > > applications. Therefore we are going to increase the default API rate > limit > > across the board. This should help absorb some of the costs for > applications > > attempting to do interesting things with social graph data. The number > will > > be somewhere between 101 and 200 calls but we still need to look at > growth > > projections and current hardware capacity before settling on a definite > > number. > > > > We plan to begin work on this relatively soon with the fix coming in a > few > > weeks. We do not have a planned ship date at this time but will > communicate > > specifics with developers as they are determined. We anticipate the new > > number of calls and a documented schema for the new method will be made > > available before the new method ships. Please watch this thread and > > @twitterapi for the incremental details. > > > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 >
[twitter-dev] Re: Deprecation of following and notification elements
To be blunt this is very unsatisfactory. Once again you guys are not being at all cognisant of the requirements of mobile Twitter client apps. These face much bigger problems than just the rate limit. They are constrained by physical limitations such as battery life, latency and bandwidth. And they also have to take account of carrier data charges. Every time something in your API requires an additional method call you are making life difficult for us mobile app developers who are trying to deliver a quality Twitter client to our users (who are also your users!). What annoys me too is that whenever a mobile-specific issue is raised your stock response is "handle that in a proxy". Guys, that's just not good enough. The World is going mobile and the continuing development of your API needs to take account of this. Very unhappy about this! On May 11, 10:18 pm, Doug Williams wrote: > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The > defects report that methods returning user objects (see users/show for an > example [3]) are returning incorrect or invalid values for the > element. > > The fix for this inconsistency is in fact non trivial [4]. The problem lies > within the interaction of the application logic, caching layer and database > design. The persistent data behind and values are > separate from the user data in our architecture, so to keep these elements > valid in cache alongside user objects adds a large amount of complexity. > > Developers made it obvious that these data are a priority and we want to > ensure they available. We also want to guarantee they are accurate and that > performance remains good. Given the problems explained above, we are going > to be making a number of changes to the API so that you can rely on the > or data. > > Deprecations: > The following elements are to be removed from all returned user objects > returned by the API: > > 1) > 2) > > This deprecation will not occur until we finish the following: > > Additions: > To continue to provide access to this data we will be creating a new method: > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > will use a method similar to that described in this issue to deliver > , , and (in the case of > protected users) data with a single call. > > We realize this change will cause an increase in API usage for some > applications. Therefore we are going to increase the default API rate limit > across the board. This should help absorb some of the costs for applications > attempting to do interesting things with social graph data. The number will > be somewhere between 101 and 200 calls but we still need to look at growth > projections and current hardware capacity before settling on a definite > number. > > We plan to begin work on this relatively soon with the fix coming in a few > weeks. We do not have a planned ship date at this time but will communicate > specifics with developers as they are determined. We anticipate the new > number of calls and a documented schema for the new method will be made > available before the new method ships. Please watch this thread and > @twitterapi for the incremental details. > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Supporthttp://twitter.com/dougw
[twitter-dev] Re: Deprecation of following and notification elements
I'll admit I'm a little disappointed that the info won't be part of the user objects anymore (will have to rethink some of my planned features... ie. won't be able to dynamically show/hide the dm button next to tweets if it means I need an additional api call for each user) instead relying on another api call, but I'm sure you guys have your reasons. Thanks for the advanced warning :) On May 12, 7:18 am, Doug Williams wrote: > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The > defects report that methods returning user objects (see users/show for an > example [3]) are returning incorrect or invalid values for the > element. > > The fix for this inconsistency is in fact non trivial [4]. The problem lies > within the interaction of the application logic, caching layer and database > design. The persistent data behind and values are > separate from the user data in our architecture, so to keep these elements > valid in cache alongside user objects adds a large amount of complexity. > > Developers made it obvious that these data are a priority and we want to > ensure they available. We also want to guarantee they are accurate and that > performance remains good. Given the problems explained above, we are going > to be making a number of changes to the API so that you can rely on the > or data. > > Deprecations: > The following elements are to be removed from all returned user objects > returned by the API: > > 1) > 2) > > This deprecation will not occur until we finish the following: > > Additions: > To continue to provide access to this data we will be creating a new method: > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > will use a method similar to that described in this issue to deliver > , , and (in the case of > protected users) data with a single call. > > We realize this change will cause an increase in API usage for some > applications. Therefore we are going to increase the default API rate limit > across the board. This should help absorb some of the costs for applications > attempting to do interesting things with social graph data. The number will > be somewhere between 101 and 200 calls but we still need to look at growth > projections and current hardware capacity before settling on a definite > number. > > We plan to begin work on this relatively soon with the fix coming in a few > weeks. We do not have a planned ship date at this time but will communicate > specifics with developers as they are determined. We anticipate the new > number of calls and a documented schema for the new method will be made > available before the new method ships. Please watch this thread and > @twitterapi for the incremental details. > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Supporthttp://twitter.com/dougw
[twitter-dev] Deprecation of following and notification elements
Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. The defects report that methods returning user objects (see users/show for an example [3]) are returning incorrect or invalid values for the element. The fix for this inconsistency is in fact non trivial [4]. The problem lies within the interaction of the application logic, caching layer and database design. The persistent data behind and values are separate from the user data in our architecture, so to keep these elements valid in cache alongside user objects adds a large amount of complexity. Developers made it obvious that these data are a priority and we want to ensure they available. We also want to guarantee they are accurate and that performance remains good. Given the problems explained above, we are going to be making a number of changes to the API so that you can rely on the or data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) 2) This deprecation will not occur until we finish the following: Additions: To continue to provide access to this data we will be creating a new method: Issue 532 [4] outlines the need to perform a mutual following lookup. We will use a method similar to that described in this issue to deliver , , and (in the case of protected users) data with a single call. We realize this change will cause an increase in API usage for some applications. Therefore we are going to increase the default API rate limit across the board. This should help absorb some of the costs for applications attempting to do interesting things with social graph data. The number will be somewhere between 101 and 200 calls but we still need to look at growth projections and current hardware capacity before settling on a definite number. We plan to begin work on this relatively soon with the fix coming in a few weeks. We do not have a planned ship date at this time but will communicate specifics with developers as they are determined. We anticipate the new number of calls and a documented schema for the new method will be made available before the new method ships. Please watch this thread and @twitterapi for the incremental details. 1. http://code.google.com/p/twitter-api/issues/detail?id=419 2. http://code.google.com/p/twitter-api/issues/detail?id=474 3. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show 4. http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm 5. http://code.google.com/p/twitter-api/issues/detail?id=532 Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw
[twitter-dev] Re: Default Device Notification
Chris,
I'll clarify that now.
Thanks,
Doug
--
Doug Williams
Twitter Platform Support
http://twitter.com/dougw
On Thu, May 7, 2009 at 6:31 AM, Chris Carson wrote:
>
> Hi --
>
> The follow parameter (turning device notifications on or off) in
> friendships/create is not behaving as I expected. It appears that
> having the follow parameter in the post data turns device
> notifications on, no matter what value you give it. My (php) code was
> this:
>
> public function createFriendship($id = null, $user_id = null,
> $screen_name = null, $follow = false){
> //code deleted for clarity
>$params["follow"] = $follow;
>return $this->makeAPIRequest("http://twitter.com/friendships/
> create.json",$params,"POST","TwitterAPIUser");
> }
>
> Calling createFriendship(null, null, "chriscarson") would, after php
> converts false into an empty string, result in post data like this...
>
> screen_name=chriscarson&follow=
>
> I expected the API to interpret the null "follow" value as false, but
> I think it interprets the presence of "follow" as true, without
> checking the value.
>
> Anyway, I fixed by doing this...
>
> if ($follow) $params["follow"] = $follow;
>
> This results in post data ...
>
> screen_name=chriscarson
>
> This seems to be working. But maybe it'd be a good idea to clarify
> the expected values for boolean post parameters. Thanks,
>
> --Chris
>
>
>
> On Apr 22, 8:36 pm, Eric Blair wrote:
> > Damn. That was it. Thanks for the pointer.
> >
> > --Eric
> >
> > On Apr 22, 2009, at 7:58 PM, Matt Sanford wrote:
> >
> >
> >
> > > Hi Eric,
> >
> > > If you do a friendships/create?follow=true is will turn on
> > > notifications when the follower is added. Poorly namedparameter, I
> > > know.
> >
> > > — Matt
> >
> > > On Apr 22, 2009, at 04:31 PM, Eric Blair wrote:
> >
> > >> Is there any condition that would result in device notification
> > >> being active immediately after following somebody via friendship/
> > >> create? I have a user who's telling me they're getting SMS updates
> > >> from new friends and following them in my app, but I don't see
> > >> anything in my logs indicating the I called /notifications/follow.
> >
> > >> I've looked through the API docs and the settings on Twitter and
> > >> nothing's jumped out at me.
> >
> > >> Thanks,
> > >> --Eric
>
[twitter-dev] Re: Default Device Notification
Hi --
The follow parameter (turning device notifications on or off) in
friendships/create is not behaving as I expected. It appears that
having the follow parameter in the post data turns device
notifications on, no matter what value you give it. My (php) code was
this:
public function createFriendship($id = null, $user_id = null,
$screen_name = null, $follow = false){
//code deleted for clarity
$params["follow"] = $follow;
return $this->makeAPIRequest("http://twitter.com/friendships/
create.json",$params,"POST","TwitterAPIUser");
}
Calling createFriendship(null, null, "chriscarson") would, after php
converts false into an empty string, result in post data like this...
screen_name=chriscarson&follow=
I expected the API to interpret the null "follow" value as false, but
I think it interprets the presence of "follow" as true, without
checking the value.
Anyway, I fixed by doing this...
if ($follow) $params["follow"] = $follow;
This results in post data ...
screen_name=chriscarson
This seems to be working. But maybe it'd be a good idea to clarify
the expected values for boolean post parameters. Thanks,
--Chris
On Apr 22, 8:36 pm, Eric Blair wrote:
> Damn. That was it. Thanks for the pointer.
>
> --Eric
>
> On Apr 22, 2009, at 7:58 PM, Matt Sanford wrote:
>
>
>
> > Hi Eric,
>
> > If you do a friendships/create?follow=true is will turn on
> > notifications when the follower is added. Poorly namedparameter, I
> > know.
>
> > — Matt
>
> > On Apr 22, 2009, at 04:31 PM, Eric Blair wrote:
>
> >> Is there any condition that would result in device notification
> >> being active immediately after following somebody via friendship/
> >> create? I have a user who's telling me they're getting SMS updates
> >> from new friends and following them in my app, but I don't see
> >> anything in my logs indicating the I called /notifications/follow.
>
> >> I've looked through the API docs and the settings on Twitter and
> >> nothing's jumped out at me.
>
> >> Thanks,
> >> --Eric
[twitter-dev] Re: Default Device Notification
Damn. That was it. Thanks for the pointer. --Eric On Apr 22, 2009, at 7:58 PM, Matt Sanford wrote: Hi Eric, If you do a friendships/create?follow=true is will turn on notifications when the follower is added. Poorly named parameter, I know. — Matt On Apr 22, 2009, at 04:31 PM, Eric Blair wrote: Is there any condition that would result in device notification being active immediately after following somebody via friendship/ create? I have a user who's telling me they're getting SMS updates from new friends and following them in my app, but I don't see anything in my logs indicating the I called /notifications/follow. I've looked through the API docs and the settings on Twitter and nothing's jumped out at me. Thanks, --Eric
[twitter-dev] Re: Default Device Notification
Hi Eric, If you do a friendships/create?follow=true is will turn on notifications when the follower is added. Poorly named parameter, I know. — Matt On Apr 22, 2009, at 04:31 PM, Eric Blair wrote: Is there any condition that would result in device notification being active immediately after following somebody via friendship/ create? I have a user who's telling me they're getting SMS updates from new friends and following them in my app, but I don't see anything in my logs indicating the I called /notifications/follow. I've looked through the API docs and the settings on Twitter and nothing's jumped out at me. Thanks, --Eric
[twitter-dev] Default Device Notification
Is there any condition that would result in device notification being active immediately after following somebody via friendship/create? I have a user who's telling me they're getting SMS updates from new friends and following them in my app, but I don't see anything in my logs indicating the I called /notifications/follow. I've looked through the API docs and the settings on Twitter and nothing's jumped out at me. Thanks, --Eric
[twitter-dev] Re: What precisely does notification mean?
Thanks...that helps clear this confusion up. On Apr 17, 4:38 pm, Doug Williams wrote: > Allen, > Notifications are for device notifications (like SMS or IM) if the user has > them enabled. Following means that a user's updates are included in your > timeline. Notifications mean that a user's updates appear in your timeline > AND are sent to your enabled devices. > > Doug Williams > Twitter API Supporthttp://twitter.com/dougw > > On Fri, Apr 17, 2009 at 3:13 PM, Allen wrote: > > > Seeing all the posts here, I'm getting confused as to what the term > > notification means. Does it mean, for example: > > > a) the person has it enabled to get email when someone starts > > following them > > > b) the person has it enabled to notices sent to their mobile phone > > > c) something else? > > > Seriously, I've seen the term used in different contexts and the api > > says "Enables notifications for updates from the specified user to the > > authenticating user. Returns the specified user when successful." but > > then it says that notification is a "boolean indicating if a user is > > receiving device updates for a given user", which sounds like it's a > > mobile phone (i.e., device). > > > Can anybody clarify what this is? > > > Thanks > > Allen
[twitter-dev] Re: What precisely does notification mean?
Allen, Notifications are for device notifications (like SMS or IM) if the user has them enabled. Following means that a user's updates are included in your timeline. Notifications mean that a user's updates appear in your timeline AND are sent to your enabled devices. Doug Williams Twitter API Support http://twitter.com/dougw On Fri, Apr 17, 2009 at 3:13 PM, Allen wrote: > > Seeing all the posts here, I'm getting confused as to what the term > notification means. Does it mean, for example: > > a) the person has it enabled to get email when someone starts > following them > > b) the person has it enabled to notices sent to their mobile phone > > c) something else? > > Seriously, I've seen the term used in different contexts and the api > says "Enables notifications for updates from the specified user to the > authenticating user. Returns the specified user when successful." but > then it says that notification is a "boolean indicating if a user is > receiving device updates for a given user", which sounds like it's a > mobile phone (i.e., device). > > Can anybody clarify what this is? > > Thanks > Allen >
[twitter-dev] What precisely does notification mean?
Seeing all the posts here, I'm getting confused as to what the term notification means. Does it mean, for example: a) the person has it enabled to get email when someone starts following them b) the person has it enabled to notices sent to their mobile phone c) something else? Seriously, I've seen the term used in different contexts and the api says "Enables notifications for updates from the specified user to the authenticating user. Returns the specified user when successful." but then it says that notification is a "boolean indicating if a user is receiving device updates for a given user", which sounds like it's a mobile phone (i.e., device). Can anybody clarify what this is? Thanks Allen
Re: Whitelisting notification?
I requested to be whitelisted on Tuesday, and still haven't heard anything. Nor has the account or IP be granted whitelisting (still running into 400 Bad Request errors). On Feb 1, 9:04 am, Rob Ashton wrote: > I was wondering this myself, it's been over a week since I requested > auth and it hadn't occured to me that I might have been whitelisted > and simply not notified. > > Gilles Frydman wrote: > > Sorry for the /trivial/ question but do you send any notification to those > > who request whitelisting?If so, how is the notification sent? > > > -- > > Gilles Frydman
Re: Whitelisting notification?
I was wondering this myself, it's been over a week since I requested auth and it hadn't occured to me that I might have been whitelisted and simply not notified. Gilles Frydman wrote: > Sorry for the /trivial/ question but do you send any notification to those > who request whitelisting?If so, how is the notification sent? > > -- > Gilles Frydman
Re: Whitelisting notification?
You will get an email. Usually within 72 hours but occasionally longer. On Sat, Jan 31, 2009 at 14:11, Gilles Frydman wrote: > Sorry for the /trivial/ question but do you send any notification to those > who request whitelisting?If so, how is the notification sent? > > -- > Gilles Frydman > -- | Abraham Williams | http://the.hackerconundrum.com | Web608 | Community Evangelist | http://web608.org | gg&d | betaGeek | http://girlsgeeksanddating.com | Micro-email: http://userscripts.org/scripts/show/38822 | This email is: [] blogable [x] ask first [] private
Whitelisting notification?
Sorry for the /trivial/ question but do you send any notification to those who request whitelisting?If so, how is the notification sent? -- Gilles Frydman
old notification / follow bug?
I think one used to be able, via the API, to turn on notifications between a twitterer and another, *without* actually following that other. I think I accidentally did this to a number of twinfluence.com users who requested to follow me as the author ( a couple of months ago). I base this on: a) a number of users who claim to get my updates as direct messages or texts, but b) are not currently following me. There are also those that *are* following me, but get my tweets as texts or direct messages, and can't figure out how to turn that off. It doesn't seem to be within my ability to use the API to go back and find / fix these users (even if I stored their passwords, which I DO NOT). I just tested the API, and I can't seem to recreate that situation now, so perhaps the loophole got fixed. Does anybody have any similar experiences, or suggestions how I can fix this?
Re: Reply notification?
2009/1/3 Justin Hart : > Is there any notification we can set up for @replies? http://replies.twitapps.com/ Other services are also available, but that one's mine so I think it's the best ;-) -Stuart -- http://stut.net/
Re: Reply notification?
This functionality is provided by several third-party services. On Sat, Jan 3, 2009 at 09:36, zbowling wrote: > > Not directly. However, I believe you can however use a service like > Gnip (www.gnipcentral.com) and possibly set up a filter for it to call > you back on. > > I really wish twitter had a public XMPP pub/sub service that we could > all use, right now. :-) > > Zac Bowling > http://zbowling.com/ > > On Jan 3, 8:55 am, Justin Hart wrote: >> Is there any notification we can set up for @replies? > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Reply notification?
Not directly. However, I believe you can however use a service like Gnip (www.gnipcentral.com) and possibly set up a filter for it to call you back on. I really wish twitter had a public XMPP pub/sub service that we could all use, right now. :-) Zac Bowling http://zbowling.com/ On Jan 3, 8:55 am, Justin Hart wrote: > Is there any notification we can set up for @replies?
Reply notification?
Is there any notification we can set up for @replies?
Re: Notification
When you update your status (see http://apiwiki.twitter.com/REST+API+Documentation#update) you'll get back a representation of that status in the requested format. On Mon, Nov 10, 2008 at 8:57 PM, saranya <[EMAIL PROTECTED]> wrote: > > Hi, >I need to get a notification in my application when ever i update > some thing in my twitter.. > is there any such way to get such notification.. > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Notification for Updates
There are lots of ways to get the most recent updates via the REST API: http://apiwiki.twitter.com/REST+API+Documentation. We don't currently support a "push" mechanism. On Mon, Nov 10, 2008 at 11:34 PM, saranya saranya dakshi <[EMAIL PROTECTED]> wrote: > Hi viswa well you can do this by search api... > > On Tue, Nov 11, 2008 at 12:54 PM, VIswa <[EMAIL PROTECTED]> wrote: >> >> Hey >> >> Is there any way to get notification to the third party application >> when a tweet or update is posted in twitter >> >> Thanks >> Viswanathan > > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Notification for Updates
Hi viswa well you can do this by search api... On Tue, Nov 11, 2008 at 12:54 PM, VIswa <[EMAIL PROTECTED]> wrote: > > Hey > > Is there any way to get notification to the third party application > when a tweet or update is posted in twitter > > Thanks > Viswanathan >
Notification
Hi, I need to get a notification in my application when ever i update some thing in my twitter.. is there any such way to get such notification..
Notification for Updates
Hey Is there any way to get notification to the third party application when a tweet or update is posted in twitter Thanks Viswanathan
Re: Notification Methods
Twitter has two levels of preferences when it comes to following someone's updates. If you follow a user (in the nomenclature of the API, befriend them), you'll see their updates on the web and in API clients. If you turn notifications on for them with the method that you mentioned, you'll get their updates to your mobile device if you've set one up. On Mon, Oct 27, 2008 at 12:47 AM, Clifton <[EMAIL PROTECTED]> wrote: > > Sorry if this is a duplicate message... > > I'm new to this and and could use some input. Can anyone help me > understand this: > > > Notification Methods > > follow > > Enables notifications for updates from the specified user to the > authenticating user. Returns the specified user when successful. > > URL:http://twitter.com/notifications/follow/id.format > > Formats: xml, json > > Method(s): POST > > Parameters: > >* id. Required. The ID or screen name of the user to follow. > Ex: > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Notification Methods
Sorry if this is a duplicate message... I'm new to this and and could use some input. Can anyone help me understand this: Notification Methods follow Enables notifications for updates from the specified user to the authenticating user. Returns the specified user when successful. URL:http://twitter.com/notifications/follow/id.format Formats: xml, json Method(s): POST Parameters: * id. Required. The ID or screen name of the user to follow. Ex:
