[twitter-dev] Unable to set source parameter while submitting tweets
Hi, This is from a desktop application i m trying to come up with. I am able to successfully submit the tweets, however for some reasons I am unable to display the source of my application (It always shows from web) It's an adobe air application and I am sending the following X- Twitter-* headers as follows: request.requestHeaders = new Array(); request.requestHeaders.push(new air.URLRequestHeader(Authorization, Basic +util.base64_encode(username:password))); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter- Client, Altertunes)); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter-Client- Version, 1.0)); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter-Client- URL, http://altertunes.com/twitter.xml;)); I am also sending the source parameter along with the POST request as follows: var variables = new air.URLVariables(); variables[status] = tweet; variables[source] = Altertunes; request.data = variables; However I am still unable to set the source to Altertunes. Can someone point me to the right method? Regards, Abhinav
[twitter-dev] Re: Unable to set source parameter while submitting tweets
Do you have the source parameter Altertunes registered with Twitter? Thanks, Doug Doug Williams | Platform Support | Twitter, Inc. 539 Bryant St. Suite 402, San Francisco, CA 94107 http://twitter.com/dougw On Sun, May 10, 2009 at 1:41 PM, imoracle mailsforabhi...@gmail.com wrote: Hi, This is from a desktop application i m trying to come up with. I am able to successfully submit the tweets, however for some reasons I am unable to display the source of my application (It always shows from web) It's an adobe air application and I am sending the following X- Twitter-* headers as follows: request.requestHeaders = new Array(); request.requestHeaders.push(new air.URLRequestHeader(Authorization, Basic +util.base64_encode(username:password))); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter- Client, Altertunes)); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter-Client- Version, 1.0)); request.requestHeaders.push(new air.URLRequestHeader(X-Twitter-Client- URL, http://altertunes.com/twitter.xml;)); I am also sending the source parameter along with the POST request as follows: var variables = new air.URLVariables(); variables[status] = tweet; variables[source] = Altertunes; request.data = variables; However I am still unable to set the source to Altertunes. Can someone point me to the right method? Regards, Abhinav
[twitter-dev] Re: trouble with twitter in iframe!
Plenty of integration reasons you might use an iframe for, that have little or nothing to do with Twitter itself. Maybe you're using and re-using the same form in many places ... you might just stick it in an iframe, with that form being responsible for the API calls. Kind of like a quick app I put together for someone last week, www.twiij.com. They're using a FormSpring form, which we popped in an iframe for integration with WordPress without needing a second, local copy of the form. Just sayin', you very possibly might make API calls from an iframe. Just because the circumstance doesn't pop into mind, doesn't mean it's not valid or even common. Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera On Sun, May 10, 2009 at 5:41 AM, hjb ha...@heatonmoor.com wrote: You cannot place a twitter user page within an iframe. This was disabled for security reasons. If you need something like this, your best bet is to write a script to query the API and put that in your iframe. In that case you probably wouldn't use an iframe ;-)
[twitter-dev] Re: Streaming API Terms Of Service change - multiple simultaneous logins discouraged
Oh god. Please share where is this twitter-announce list? -- Hwee-Boon On May 10, 12:51 pm, Jesse Stay jesses...@gmail.com wrote: Not to be picky, but can we get these announcements on the twitter-announce list in the future? Who is this John and is he a real Twitter employee? On Sat, May 9, 2009 at 10:04 PM, John Kalucki jkalu...@gmail.com wrote: Note: The Streaming API is currently under a limited alpha test, details below. Multiple concurrent connections from the same account are discouraged on the Streaming API. Starting on or after the afternoon of Monday, May 11th (22:00:00 11-May-2009 UTC) the service will gently enforce this policy. A later release will fully enforce this policy. Subsequent connections from the same account will cause previously established connections to be disconnected. In some cases, this might cause operational difficulties for developers who are using the restricted resources. For example, a developer's staging test might knock that developer's production / gardenhose feed offline. Non-production uses should connect to the / spritzer resource with a secondary account to avoid these conflicts. We may, on a case-by-case basis, grant exceptions to this policy as we work through the alpha test. We will attempt to balance ease-of-use, resource consumption and abuse prevention. -John Kalucki - Services, Twitter Inc. http://twitter.com/jkalucki Important Alpha Test Note: The Streaming API (aka Hosebird) is currently under an alpha test. All developers using the Streaming API must tolerate possible unannounced and extended periods of unavailability, especially during off-hours, Pacific Time. New features, resources and policies are being deployed on very little, if any, notice. Any developer may experiment with the unrestricted resources and provide feedback via this list. Access to restricted resources is extremely limited and is only granted on a case-by-case basis after acceptance of an additional terms of service document. Documentation is available: http://apiwiki.twitter.com/Streaming-API-Documentation.
[twitter-dev] Re: Streaming API Terms Of Service change - multiple simultaneous logins discouraged
Nice work guys, talk about the firehose has been floating around for ages, great to see it finally appear and with numerous variants available (thats a bonus). I personally don't have any use for it (yet) but I'm sure it'll please quite a few. On May 10, 2:04 pm, John Kalucki jkalu...@gmail.com wrote: Note: The Streaming API is currently under a limited alpha test, details below. Multiple concurrent connections from the same account are discouraged on the Streaming API. Starting on or after the afternoon of Monday, May 11th (22:00:00 11-May-2009 UTC) the service will gently enforce this policy. A later release will fully enforce this policy. Subsequent connections from the same account will cause previously established connections to be disconnected. In some cases, this might cause operational difficulties for developers who are using the restricted resources. For example, a developer's staging test might knock that developer's production / gardenhose feed offline. Non-production uses should connect to the / spritzer resource with a secondary account to avoid these conflicts. We may, on a case-by-case basis, grant exceptions to this policy as we work through the alpha test. We will attempt to balance ease-of-use, resource consumption and abuse prevention. -John Kalucki - Services, Twitter Inc.http://twitter.com/jkalucki Important Alpha Test Note: The Streaming API (aka Hosebird) is currently under an alpha test. All developers using the Streaming API must tolerate possible unannounced and extended periods of unavailability, especially during off-hours, Pacific Time. New features, resources and policies are being deployed on very little, if any, notice. Any developer may experiment with the unrestricted resources and provide feedback via this list. Access to restricted resources is extremely limited and is only granted on a case-by-case basis after acceptance of an additional terms of service document. Documentation is available:http://apiwiki.twitter.com/Streaming-API-Documentation.
[twitter-dev] Regex for @replies
Hi guys, For an application I'm working on, we have a single table for 'tweets' and another for DMs. We're linking TwitterUsers to Tweets with a many:many, and a simple flag to specify if the tweet is a reply/ mention. We first pull in messages from the user_timeline feed, then the mentions feed. As such, we'd like to check if any of the messages in user_timeline feed is actually a reply. Could anybody clarify the exact rules that are used to determine whether a string is a reply/mention? i.e. preceded by start-of-string or non-word character... followed by space, comma, period or end of message... case insensitive... [not even sure if these are correct! :) ] Currently I'm using: /(?![^\W_])@%s(?![^\W_])/i with %s replaced by the user's screen name. Perhaps one of the devs could share the exact rules (or even the regex), or propose a nicer mechanism for detecting replies. (I did propose checking for replies before tweets, but these update threads are run asynchronously). Cheers
[twitter-dev] Re: Send @replies/mentions via SMS?
Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp://twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Send @replies/mentions via SMS?
Hi, Just to let you know, I developed www.twe2.com exactly for this purpose. However, we have just been blocked by our SMS provider. It is a shame really because we sent 2 million SMS's to the Twitter community, Paul 2009/5/11 Arik Fraimovich arik...@gmail.com Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp:// twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Send @replies/mentions via SMS?
Why were you blocked? And there seems to be a lot of competition in this space (SMS Gateway providers) can’t you just go to someone else? -- Patrick Burrows http://Categorical.ly (the Best Twitter Client Possible) @Categorically From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Paul Kinlan Sent: Monday, May 11, 2009 9:44 AM To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Send @replies/mentions via SMS? Hi, Just to let you know, I developed www.twe2.com exactly for this purpose. However, we have just been blocked by our SMS provider. It is a shame really because we sent 2 million SMS's to the Twitter community, Paul 2009/5/11 Arik Fraimovich arik...@gmail.com Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp://twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Send @replies/mentions via SMS?
If this is just for yourself, then you could send them through your carrier provided SMS to email gateway (as far as I know, every carrier provides one.) It is an email address that you can use to send yourself text messages. For instance, for ATT, it is yourphonenumber@txt.att.net. An email sent there will show up as a txt message on that person's phone. As far as actually getting the replies from Twitter -- polling every minute or so is the only way. Oh, and if this is for more than just yourself, there are 3rd party SMS Gateways that know all the formats for the different mobile carriers. Check out: http://en.wikipedia.org/wiki/SMS_gateways -- Patrick Burrows http://Categorical.ly @Categorically -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of TjL Sent: Monday, May 11, 2009 1:16 AM To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Send @replies/mentions via SMS? I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed in http://twitter.com/devices :-) *ahem* But, since it isn't :-) My idea has been to fetch the http://twitter.com/statuses/mentions.format every minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Send @replies/mentions via SMS?
Hi, We don't know why we were blocked, we had a commercial contract in place - but the provider aren't very forthcomming. The model that was used was an Adsense for mobiles, which meant that we were supposed to be paid for every message we processed, however the network never attached any adverts other than their own so we never got paid (but that has been the status quo for the last month). We were in talks with another company to buy our service from us and still use Wadja - we enquired to with Wadja to see if our contract was transferable; they cut us off. Finding another SMS gateway that will send messages worldwide for free is going to be hard - there is a reason why twitter pulled out of many markets (until they negotiated better deals - Vodafone etc). So if any twitters out there want to talk or know any one who can help we are all ears. To answer another question: not many phone networks provide Email to SMS - after all there is lots of money to be had for sending SMS's, even a 1pence/cent per SMS. But if you do have a provider that can accept emails then the whole process if very easy to replicate. Paul. 2009/5/11 Patrick Burrows pburr...@categorical.ly Why were you blocked? And there seems to be a lot of competition in this space (SMS Gateway providers) can’t you just go to someone else? -- Patrick Burrows http://Categorical.ly (the Best Twitter Client Possible) @Categorically *From:* twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] *On Behalf Of *Paul Kinlan *Sent:* Monday, May 11, 2009 9:44 AM *To:* twitter-development-talk@googlegroups.com *Subject:* [twitter-dev] Re: Send @replies/mentions via SMS? Hi, Just to let you know, I developed www.twe2.com exactly for this purpose. However, we have just been blocked by our SMS provider. It is a shame really because we sent 2 million SMS's to the Twitter community, Paul 2009/5/11 Arik Fraimovich arik...@gmail.com Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp:// twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Public Timeline Frozen (Again)
This should be fixed. The database the public timeline service was pointing to went down. This problem has been fixed and a permanent/dynamic solution was put in place to ensure this doesn't happen again. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Sun, May 10, 2009 at 12:11 PM, Doug Williams d...@twitter.com wrote: This is the second report I am seeing. I'll open a ticket. Given that it is the weekend it may take a few hours to restart. I'll update this thread with any information. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Sun, May 10, 2009 at 6:31 AM, mattarnold1977 matt.arnold.1...@gmail.com wrote: Not sure if this is an outcome of the site maintenance, but it looks like the public timeline has been sending out the same statuses since about 9:20pm on 5/8/09. The timeline was frozen last week, but was fixed. Thus, I'm guessing this is a result of the maintenance that was just performed. Please let us know if this is a known issue.
[twitter-dev] Re: xml feed for data mining is not fresh
This should be fixed. The database the public timeline service was pointing to went down. This problem has been fixed and a permanent/dynamic solution was put in place to ensure this doesn't happen again. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Sun, May 10, 2009 at 1:27 PM, tweetip twee...@mac.com wrote: Doug - the feed died on 05/08 at ~ 15:00 pdt. hth.
[twitter-dev] Re: Send @replies/mentions via SMS?
hi, I am trying to develop an application using twitter API's(using twitter4j jar file). Can you suggest me a method to acess users replies without knowing the users password(I have the users username in the data base). Surya Sravanthi On Mon, May 11, 2009 at 7:14 PM, Paul Kinlan paul.kin...@gmail.com wrote: Hi, Just to let you know, I developed www.twe2.com exactly for this purpose. However, we have just been blocked by our SMS provider. It is a shame really because we sent 2 million SMS's to the Twitter community, Paul 2009/5/11 Arik Fraimovich arik...@gmail.com Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp://twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Send @replies/mentions via SMS?
That sure is odd. I know this is off-topic, but have you tried to see if your customers would be willing to pay for the service you offer? Actually, it sounds like that is what you are going to have to do… -- Patrick Burrows http://Categorical.ly (the Best Twitter Client Possible) @Categorically From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Paul Kinlan Sent: Monday, May 11, 2009 10:56 AM To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Send @replies/mentions via SMS? Hi, We don't know why we were blocked, we had a commercial contract in place - but the provider aren't very forthcomming. The model that was used was an Adsense for mobiles, which meant that we were supposed to be paid for every message we processed, however the network never attached any adverts other than their own so we never got paid (but that has been the status quo for the last month). We were in talks with another company to buy our service from us and still use Wadja - we enquired to with Wadja to see if our contract was transferable; they cut us off. Finding another SMS gateway that will send messages worldwide for free is going to be hard - there is a reason why twitter pulled out of many markets (until they negotiated better deals - Vodafone etc). So if any twitters out there want to talk or know any one who can help we are all ears. To answer another question: not many phone networks provide Email to SMS - after all there is lots of money to be had for sending SMS's, even a 1pence/cent per SMS. But if you do have a provider that can accept emails then the whole process if very easy to replicate. Paul. 2009/5/11 Patrick Burrows pburr...@categorical.ly Why were you blocked? And there seems to be a lot of competition in this space (SMS Gateway providers) can’t you just go to someone else? -- Patrick Burrows http://Categorical.ly (the Best Twitter Client Possible) @Categorically From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Paul Kinlan Sent: Monday, May 11, 2009 9:44 AM To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Send @replies/mentions via SMS? Hi, Just to let you know, I developed www.twe2.com exactly for this purpose. However, we have just been blocked by our SMS provider. It is a shame really because we sent 2 million SMS's to the Twitter community, Paul 2009/5/11 Arik Fraimovich arik...@gmail.com Someone already developed an application that forwards mentions to DM (see here: http://apiwiki.twitter.com/Application-Ideas). When I tried it, it didn't work that good, but I think he did some changes since then. On May 11, 8:15 am, TjL luo...@gmail.com wrote: I've been banging my head against this for several days (when I've had free time) and wonder if maybe someone has already invented this wheel. I'm looking for a way to get @replies (sorry, I mean mentions) via SMS. *ahem* Ideally this would be an officially supported option listed inhttp://twitter.com/devices:-) *ahem* But, since it isn't :-) My idea has been to fetch thehttp://twitter.com/statuses/mentions.formatevery minute or so, check against a cache of previously sent mentions and send the new ones (as DMs to myself, since I have DMs forwarded to my cell via SMS already). This seems HUGELY inefficient (i.e. there will be a LOT of minutes throughout the day which return no new mentions) but I can't think of a more efficient way of getting them in a fairly timely manner. Thanks for any pointers. TjL
[twitter-dev] Re: Wildcards in Search API
If you aren't trying to do this in realtime you can get around this by doing a broad search and storing the results in a MySQL database. You could then play with the data and apply some more advanced filters to it. On May 1, 12:03 pm, hill79 hil...@googlemail.com wrote: Insanely quick replies - thanks :) On May 1, 4:58 pm, Matt Sanford m...@twitter.com wrote: Hi there, Nope, sorry to say we do not support wild cards. We've discussed it in the past internally but there is no good way to make it work fast enough to be useful based on our current system. Thanks; – Matt Sanford / @mzsanford Twitter Dev On May 1, 2009, at 8:55 AM, hill79 wrote: Is there a wildcard for search terms through the API? The 140char limit on the URL is playing havoc with something I'm trying to do and being able to shorten my search query using wildcards would help massively! I've searched the group and can't find an answer to this - although I suspect the lack of information gives me the answer I need...
[twitter-dev] Re: OAuth and Classic ASP
Any joy with this yet? I've looked at it a few times but have yet to see the light... Will monitor this thread for any updates. Many thanks Justin On May 1, 4:41 pm, Richard L richard.lockw...@gmail.com wrote: Hi Robert, I'm also looking into this once I get my .NET version problems sorted out - will let you know how I get on! All the best, Richard. On May 1, 4:36 pm, Robert robertdd...@gmail.com wrote: I am looking for some example code that I can use with a Classic ASP legacy app. I am looking for a way to use oAuth with Classic ASP. Any help would be appreciated. Thanks in advance.
[twitter-dev] Re: Regex for @replies
The classic definition of an @reply is any tweet that starts with @user. If you perfrom a to:user (e.g. to:dougw) query at search.twitter.com you will only get @replies. @replies were converted to mentions after we realized people didn't just @reply. Mentions are any tweet that contain @user within the text of the tweet. So @replies are a subset of mentions. Any non-alphanumeric (where alphanumeric is a-z, 0-9, or _) can terminate the username. For instance: hi @dougw, you look dapper today is a mention. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Mon, May 11, 2009 at 2:36 AM, stasisme...@googlemail.com stasisme...@googlemail.com wrote: Hi guys, For an application I'm working on, we have a single table for 'tweets' and another for DMs. We're linking TwitterUsers to Tweets with a many:many, and a simple flag to specify if the tweet is a reply/ mention. We first pull in messages from the user_timeline feed, then the mentions feed. As such, we'd like to check if any of the messages in user_timeline feed is actually a reply. Could anybody clarify the exact rules that are used to determine whether a string is a reply/mention? i.e. preceded by start-of-string or non-word character... followed by space, comma, period or end of message... case insensitive... [not even sure if these are correct! :) ] Currently I'm using: /(?![^\W_])@%s(?![^\W_])/i with %s replaced by the user's screen name. Perhaps one of the devs could share the exact rules (or even the regex), or propose a nicer mechanism for detecting replies. (I did propose checking for replies before tweets, but these update threads are run asynchronously). Cheers
[twitter-dev] Re: Regex for @replies
Thanks Doug, that's a great help. How about preceding? i.e. should t...@dougw, _...@dougw or @dougw create mentions? The main concern here obviously is email addresses. And finally, are screen names case sensitive? :) Cheers On May 11, 6:07 pm, Doug Williams d...@twitter.com wrote: The classic definition of an @reply is any tweet that starts with @user. If you perfrom a to:user (e.g. to:dougw) query at search.twitter.com you will only get @replies. @replies were converted to mentions after we realized people didn't just @reply. Mentions are any tweet that contain @user within the text of the tweet. So @replies are a subset of mentions. Any non-alphanumeric (where alphanumeric is a-z, 0-9, or _) can terminate the username. For instance: hi @dougw, you look dapper today is a mention. Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 2:36 AM, stasisme...@googlemail.com stasisme...@googlemail.com wrote: Hi guys, For an application I'm working on, we have a single table for 'tweets' and another for DMs. We're linking TwitterUsers to Tweets with a many:many, and a simple flag to specify if the tweet is a reply/ mention. We first pull in messages from the user_timeline feed, then the mentions feed. As such, we'd like to check if any of the messages in user_timeline feed is actually a reply. Could anybody clarify the exact rules that are used to determine whether a string is a reply/mention? i.e. preceded by start-of-string or non-word character... followed by space, comma, period or end of message... case insensitive... [not even sure if these are correct! :) ] Currently I'm using: /(?![^\W_])@%s(?![^\W_])/i with %s replaced by the user's screen name. Perhaps one of the devs could share the exact rules (or even the regex), or propose a nicer mechanism for detecting replies. (I did propose checking for replies before tweets, but these update threads are run asynchronously). Cheers
[twitter-dev] Re: all replies by friends
On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Twitter Development Talk group. To post to this group, send email to twitter-development-talk@googlegroups.com To unsubscribe from this group, send email to twitter-development-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/twitter-development-talk?hl=en -~--~~~~--~~--~--~---
[twitter-dev] Re: all replies by friends
I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] Re: Send @replies/mentions via SMS?
Well, I started over and about two hours later I had a script written. I've been testing / tweaking it today and it does seem to work. Basic premise is fairly simple, it checks http://twitter.com/statuses/mentions.rss?since_id=$LAST_ID; where $LAST_ID is stored in a text file as the last ID that was found/forwarded. I then send the message as a DM to myself, which has the added benefit of being able to use the http://twitter.com/devices setting for quiet hours already. (I have DMs sent to forward to my cell already) I also built in some rudimentary filtering to avoid some *people* (such as reTweet bots) and some regex (such as RT @tj and (via @tj) since I don't need/want those sent via SMS. One benefit of using the 'mentions' API vs the search API (which was what I had originally tried) is that it automatically excludes people that you have blocked, which search does not. My plan is to check it out for a few days, and if it seems to work I'll write up a description of how it works and post the code as well. If anyone would like to see it in its current state, drop me a note (preferably offlist, so everyone doesn't have to see it) at luo...@gmail.com TjL
[twitter-dev] Zero status_count with /users/show
The REST API is reporting the status_count as zero for the following user, even though there are quite a few updates under the user's account: https://twitter.com/users/show/MoorparkRealtor.xml I'm also receiving no statuses when I request the user's timeline. I've only encountered this one user with the problem. Is this a systemic bug, or an isolated incident?
[twitter-dev] Re: all replies by friends
There is a setting to change this behavior: http://help.twitter.com/forums/23786/entries/14595 Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Mon, May 11, 2009 at 10:44 AM, Chad Etzel jazzyc...@gmail.com wrote: I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] Re: Zero status_count with /users/show
My apologies! I was looking at a different user in a different terminal and I've been staring at this screen too long. status_count is reporting accurately. Sorry for the false alarm. On May 11, 1:25 pm, iematthew matthew.dai...@ientryinc.com wrote: The REST API is reporting the status_count as zero for the following user, even though there are quite a few updates under the user's account: https://twitter.com/users/show/MoorparkRealtor.xml I'm also receiving no statuses when I request the user's timeline. I've only encountered this one user with the problem. Is this a systemic bug, or an isolated incident?
[twitter-dev] Re: all replies by friends
Thanks, I'm familiar with the setting. Somehow the setting does not have any effect with the account I'm testing with: not when logged in to twitter.com, and not when using statuses/friends_timeline. Chad's posting made me do some tests with two other accounts: there the setting works as it should. The only difference between the accounts I can think of is that the misbehaving account is the one I used when applying for a higher rate limit (20,000). Could there be a relation? thanks, Jack On May 11, 8:38 pm, Doug Williams d...@twitter.com wrote: There is a setting to change this behavior: http://help.twitter.com/forums/23786/entries/14595 Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 10:44 AM, Chad Etzel jazzyc...@gmail.com wrote: I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] Notifications info vague/wrong
1) http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show suggests that you can use any of: xml json rss atom but rss and atom are not working at all: Try this on the commandline: for EXT in xml json rss atom do; echo $EXT: curl http://twitter.com/users/show.$EXT?screen_name=moltz; done and you'll see that RSS and ATOM return nothing at all. 2) If I go to http://twitter.com/moltz I see that notifications are ON, but if I check via commandline it says: $ curl --netrc http://twitter.com/users/show.xml?screen_name=moltz; returns notifications0/notifications and $ curl --netrc http://twitter.com/users/show.json?screen_name=moltz; returns notifications:0 if I turn OFF notifications, XML returns notificationsfalse/notifications and json returns notifications:false soo does notifications = 0 mean you have notifications turned on and notifications = false means you do not? Sounds like a job for either 0 and 1 or true and false. Am I missing something? TjL
[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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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: Notifications info vague/wrong
Please see the recent message on following and notification deprecation: http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Mon, May 11, 2009 at 1:27 PM, TjL luo...@gmail.com wrote: 1) http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show suggests that you can use any of: xml json rss atom but rss and atom are not working at all: Try this on the commandline: for EXT in xml json rss atom do; echo $EXT: curl http://twitter.com/users/show.$EXT?screen_name=moltz; done and you'll see that RSS and ATOM return nothing at all. 2) If I go to http://twitter.com/moltz I see that notifications are ON, but if I check via commandline it says: $ curl --netrc http://twitter.com/users/show.xml?screen_name=moltz; returns notifications0/notifications and $ curl --netrc http://twitter.com/users/show.json?screen_name=moltz; returns notifications:0 if I turn OFF notifications, XML returns notificationsfalse/notifications and json returns notifications:false soo does notifications = 0 mean you have notifications turned on and notifications = false means you do not? Sounds like a job for either 0 and 1 or true and false. Am I missing something? TjL
[twitter-dev] Re: all replies by friends
We have had a debate internally (today) where we have all but decided to remove this setting in the near future. I would not create any application that relied on this. Almost all of our users leave it at the default (only show @replies to people I follow) so the cost of maintaining the setting does not translate to value in the product. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw On Mon, May 11, 2009 at 12:57 PM, voorwiel voorw...@gmail.com wrote: Thanks, I'm familiar with the setting. Somehow the setting does not have any effect with the account I'm testing with: not when logged in to twitter.com, and not when using statuses/friends_timeline. Chad's posting made me do some tests with two other accounts: there the setting works as it should. The only difference between the accounts I can think of is that the misbehaving account is the one I used when applying for a higher rate limit (20,000). Could there be a relation? thanks, Jack On May 11, 8:38 pm, Doug Williams d...@twitter.com wrote: There is a setting to change this behavior: http://help.twitter.com/forums/23786/entries/14595 Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 10:44 AM, Chad Etzel jazzyc...@gmail.com wrote: I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] Re: all replies by friends
Wait, did the default not used to be Show all @ replies (it is the first option in the dropdown box)? Did that change? Personally, I like seeing all of them as it leads me to follow new and interesting people... If this goes away, is everyone going to be set to only show @replies to people I follow ? -Chad On Mon, May 11, 2009 at 5:30 PM, Doug Williams d...@twitter.com wrote: We have had a debate internally (today) where we have all but decided to remove this setting in the near future. I would not create any application that relied on this. Almost all of our users leave it at the default (only show @replies to people I follow) so the cost of maintaining the setting does not translate to value in the product. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw
[twitter-dev] Re: all replies by friends
OK, thanks for the heads up. On May 11, 11:30 pm, Doug Williams d...@twitter.com wrote: We have had a debate internally (today) where we have all but decided to remove this setting in the near future. I would not create any application that relied on this. Almost all of our users leave it at the default (only show @replies to people I follow) so the cost of maintaining the setting does not translate to value in the product. Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 12:57 PM, voorwiel voorw...@gmail.com wrote: Thanks, I'm familiar with the setting. Somehow the setting does not have any effect with the account I'm testing with: not when logged in to twitter.com, and not when using statuses/friends_timeline. Chad's posting made me do some tests with two other accounts: there the setting works as it should. The only difference between the accounts I can think of is that the misbehaving account is the one I used when applying for a higher rate limit (20,000). Could there be a relation? thanks, Jack On May 11, 8:38 pm, Doug Williams d...@twitter.com wrote: There is a setting to change this behavior: http://help.twitter.com/forums/23786/entries/14595 Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 10:44 AM, Chad Etzel jazzyc...@gmail.com wrote: I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] Re: all replies by friends
The default is: show me: @replies to the people that I'm following. The vast majority of our users keep this default. If this setting is indeed removed this is the behavior we will use. Note: I will update the thread when/if this setting is axed (even though it's not really an API decision) to close the loop. Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw Wait, did the default not used to be Show all @ replies (it is the first option in the dropdown box)? Did that change? Personally, I like seeing all of them as it leads me to follow new and interesting people... If this goes away, is everyone going to be set to only show @replies to people I follow ? -- Do you follow me? http://twitter.com/dougw On Mon, May 11, 2009 at 2:43 PM, voorwiel voorw...@gmail.com wrote: OK, thanks for the heads up. On May 11, 11:30 pm, Doug Williams d...@twitter.com wrote: We have had a debate internally (today) where we have all but decided to remove this setting in the near future. I would not create any application that relied on this. Almost all of our users leave it at the default (only show @replies to people I follow) so the cost of maintaining the setting does not translate to value in the product. Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 12:57 PM, voorwiel voorw...@gmail.com wrote: Thanks, I'm familiar with the setting. Somehow the setting does not have any effect with the account I'm testing with: not when logged in to twitter.com, and not when using statuses/friends_timeline. Chad's posting made me do some tests with two other accounts: there the setting works as it should. The only difference between the accounts I can think of is that the misbehaving account is the one I used when applying for a higher rate limit (20,000). Could there be a relation? thanks, Jack On May 11, 8:38 pm, Doug Williams d...@twitter.com wrote: There is a setting to change this behavior: http://help.twitter.com/forums/23786/entries/14595 Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw On Mon, May 11, 2009 at 10:44 AM, Chad Etzel jazzyc...@gmail.com wrote: I'm confused now. I just pulled my friends_timeline and it is definitely showing @replies from my friends to people I don't follow. i.e. I'm getting the firehose as it pertains to my friends_timeline are you saying you're not seeing the same thing? -Chad On Mon, May 11, 2009 at 1:36 PM, voorwiel voorw...@gmail.com wrote: On May 10, 12:00 am, Abraham Williams 4bra...@gmail.com wrote: I would think that statuses/friends_timeline [1] would not be effected by @-reply settings [2]. If it is your only option is to use the search method you mentioned. The down side of this is protected accounts are not included. Indeed it isn't affected by the setting. I wonder whether it is a policy decision not to include statuses directed at non-friends in statuses/friends_timeline. I'm actually hoping that it is not in the otherwise excellent documentation simply because someone forgot to include it :) greetings, Jack
[twitter-dev] @mentions, truncation, character limits etc.
Hi. We feel compelled to briefly explain what we at escarp do. escarp is a review of brief poetry and prose distributed through Twitter. On our site (http://escarp.org) we use the API to show the most recent pieces, as well as handle comments and news. To distribute an author's bio, many Twitter reviews use a 2nd status with some sort of tag ([BIO]) to indicate this information. We elected to experiment with leaving control of this functionality in the author's hands by using @mentions and creating a script which compiles an author's bio from their Twitter profile. (http://escarp.org/ writers.php). Positive byproducts of this process for the Twitter service include requiring our writers to create a Twitter account to send submissions (most other publications accept submissions via email, as they need to also gather biographicals,) and a reduction in the number of text- messages sent. Even on Twitter itself, the @mention is an intuitive way to attribute the creative work, when the bio has been filled out. ***The problem, however, is in status truncation, and the lack of an API response to indicate usernames a status mentions. In response, we would be forced to either: 1.) reduce the character limit of our submissions 2.) create a script which loads the full status page to scrape the remaining information, or 3.) move the @mention to the front of the message. All of these, we feel, are less than ideal: - Dropping our character limit to include the @mention reduces the expressive potential of the medium, and reduces the brand identification with Twitter when we say our character limit is 140 (which, by proxy, kills the association of identifying ourselves as a 140-character journal when and if we're able to publish print anthologies, nominate pieces we've accepted for awards, or execute promotional efforts.) It also requires us to count characters in every submission. - Scraping the status information wastes your resources and ours. - Moving the @mention up just forces the truncation of the creative part of the message, making text-message distribution pointless. According to the link below, statuses longer than 140 characters will be disabled at some point in the future: http://code.google.com/p/twitter-api/issues/detail?id=133 For the reasons listed above, we'd like to appeal the terminal fate of 20 additional characters, out to text-message length (we edit the journal by phone) and request a resource-friendly method of making use of this information on the web. To further justify this cause, we were the first account followed by a number of our followers, many of whom are studying or practicing poets and fiction writers over the age of 20. Many of these people initially perceive Twitter as vapid and pointless. In our own promotional efforts, we at escarp work hard to convince writers and readers of the merits of Twitter; in our editorial efforts, we're working hard (it will be a long journey) to cultivate a Twitter-based journal worth mentioning in the same breath as storied, traditional print and electronic literary publications. Thanks for your time, thoughts and consideration, The editorial we
[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 d...@twitter.com 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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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
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 d...@twitter.com 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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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
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 davidmccorm...@gmail.com 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 d...@twitter.com 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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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.
[twitter-dev] Twitter Search methods - can we get XML instead of JSON returns?
I see that the Twitter API shows JSON objects as the returning data feed for search API calls. Can we get XML/RSS feeds instead of JSON for easier usage in some environments? Jeff
[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 davidmccorm...@gmail.com 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 d...@twitter.com 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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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: Is there a way to get the unique userid during a oauth authorization?
Verify_credentials returns id/id. That is unique.
On Mon, May 11, 2009 at 18:55, Jochen Kaechelin giss...@gissmog.de wrote:
def callback
@request_token =
OAuth::RequestToken.new(UsersController.consumer,
session[:request_token], session[:request_token_secret])
@response = UsersController.consumer.request(:get, '/account/
verify_credentials.json', @access_token, { :scheme = :query_string })
case @response
when Net::HTTPSuccess
user_info = JSON.parse(@response.body)
unless user_info['screen_name']
flash[:notice] = Authentication failed
redirect_to :action = :index
return
end
@user = User.new({ :screen_name =
user_info['screen_name'], :token = @access_token.token, :secret =
@access_token.secret })
@user.save!
..
Is there a way to get unique, never changing userid which I can store
in my local database?
I want to replace the screen_name in all API-requests with the unique
userid.
Thanx
--
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.
Sent from Madison, WI, United States
[twitter-dev] Re: Twitter Search methods - can we get XML instead of JSON returns?
http://apiwiki.twitter.com/V2-Roadmap#MergingRESTandSearchAPIs On Mon, May 11, 2009 at 19:22, Jeff Bishop jeff.bis...@gmail.com wrote: I see that the Twitter API shows JSON objects as the returning data feed for search API calls. Can we get XML/RSS feeds instead of JSON for easier usage in some environments? Jeff -- 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. Sent from Madison, WI, United States
[twitter-dev] Re: Twitter Search methods - can we get XML instead of JSON returns?
You can get .atom feeds from the Search API already... Not sure if that is close enough to XML for your needs, though... -Chad On Mon, May 11, 2009 at 8:22 PM, Jeff Bishop jeff.bis...@gmail.com wrote: I see that the Twitter API shows JSON objects as the returning data feed for search API calls. Can we get XML/RSS feeds instead of JSON for easier usage in some environments? Jeff
[twitter-dev] Re: Can't Search for This String
Thanks Chad...you're absolutely right. Thanks! On May 9, 5:38 pm, Chad Etzel jazzyc...@gmail.com wrote: Probably because Twitter considers $ by themselves to be unsearchable punctuation. They added it as a token modifier a while ago (like # for hashtags), so you could search things like $BAC, but $$ itself won't get any hits. Same as searching # by itself yields no results. StockTwits parses their friends timeline for $$ on their own, which is how they get their stock talk feed or what have you. I'm guessing this is why you're asking... (I have no affiliation with StockTwits, but this is my best guess as to how they're doing it). -Chad On Sat, May 9, 2009 at 6:32 PM, Joe McCann joseph.is...@gmail.com wrote: Anyone know why zero results for the string $$ appear when searched for on twitter? http://search.twitter.com/search?q=%24%24
[twitter-dev] Re: oAuth Chaining
No takers on this? On May 9, 2:04 pm, Joe McCann joseph.is...@gmail.com wrote: Hello Folks, I have built a simple bookmarklet (http://www.subprint.com/blog/projects/imgly_bookmarklet/ ) that utilizes Img.ly's web service for posting pictures and tweets via Img.ly's REST API. If you use Img.ly directly, via their website, they support oAuth authentication to post your photo and tweet. However, their API requires the user's twitter username and password in order to successfully post the photo and tweet via their web service. What I would like to is allow for oAuth authentication on the homepage of my application (http://www.subprint.com/labs/imgly/) and then pass along or chain the credentials for the username and password to Img.ly's API. Is this possible? I'm thinking not, but wanted to check and see if anyone has any insight in how to accomplish this feat. http://img.ly/pages/API http://www.subprint.com/blog/projects/imgly_bookmarklet/ http://www.subprint.com/labs/imgly/ Thanks! Joe McCann @joemccann
[twitter-dev] Re: oAuth Chaining
This thread might help shed some light: http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a8aaef/0f95410fdeb64284 On Mon, May 11, 2009 at 19:37, Joe McCann joseph.is...@gmail.com wrote: No takers on this? On May 9, 2:04 pm, Joe McCann joseph.is...@gmail.com wrote: Hello Folks, I have built a simple bookmarklet ( http://www.subprint.com/blog/projects/imgly_bookmarklet/ ) that utilizes Img.ly's web service for posting pictures and tweets via Img.ly's REST API. If you use Img.ly directly, via their website, they support oAuth authentication to post your photo and tweet. However, their API requires the user's twitter username and password in order to successfully post the photo and tweet via their web service. What I would like to is allow for oAuth authentication on the homepage of my application (http://www.subprint.com/labs/imgly/) and then pass along or chain the credentials for the username and password to Img.ly's API. Is this possible? I'm thinking not, but wanted to check and see if anyone has any insight in how to accomplish this feat. http://img.ly/pages/API http://www.subprint.com/blog/projects/imgly_bookmarklet/ http://www.subprint.com/labs/imgly/ Thanks! Joe McCann @joemccann -- 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. Sent from Madison, WI, United States
[twitter-dev] API Changes for May 11, 2009
Hi All, Blocking now gets more fun: - Feature (REST): Added methods to retrieve blocking information See also: Google Code Issue 9: http://code.google.com/p/twitter-api/issues/detail?id=9 See also: blocks/exists = http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-exists See also: blocks/blocking = http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-blocking See also: blocks/blocking/ids = http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-blocking-ids We are going to be moving some things around: - Deprecation Announced (REST): following and notification elements will be moved to their own method in the near future. See announcement: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/42ba883b9f8e3c6e?tvc=2 Thanks, Doug -- Doug Williams Twitter Platform Support http://twitter.com/dougw
[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 d...@twitter.com 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 davidmccorm...@gmail.com 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 d...@twitter.com 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 following 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 following and notification 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 following or notification data. Deprecations: The following elements are to be removed from all returned user objects returned by the API: 1) following 2) notifications 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 following, followedby, notification and pending (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
[twitter-dev] Re: API Changes for May 11, 2009
Any particular reason the blocks/exist function returns the information for the user requested if the block exist and a hash error response if not? I would think following the same kind of format as the friendship exist function would make more sense; something like: blockingtrue/falseblocking An error response should only be returned if the user name doesn't exist. Just my 2 cents. On May 11, 8:58 pm, Doug Williams d...@twitter.com wrote: Hi All, Blocking now gets more fun: - Feature (REST): Added methods to retrieve blocking information See also: Google Code Issue 9:http://code.google.com/p/twitter-api/issues/detail?id=9 See also: blocks/exists =http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-exists See also: blocks/blocking =http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-blocking See also: blocks/blocking/ids =http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-blocks-blocking... We are going to be moving some things around: - Deprecation Announced (REST): following and notification elements will be moved to their own method in the near future. See announcement:http://groups.google.com/group/twitter-development-talk/browse_thread... Thanks, Doug -- Doug Williams Twitter Platform Supporthttp://twitter.com/dougw
[twitter-dev] API Lock Out time for User Rate Limit
http://apiwiki.twitter.com/Rate-limiting The above page doesnt document what the effect is on the user if the User Rate limit of 100 reqs/ph is exceeded. From what I remember its an hour, but am having trouble finding this documented anywhere. Cheers M
[twitter-dev] Re: API Lock Out time for User Rate Limit
The above page doesnt document what the effect is on the user if the User Rate limit of 100 reqs/ph is exceeded. In the past, it usually involved dismemberment, but this was revised in an early version of the API and now the user simply has to wait for the next hour interval when the rate limit is reset. Personally, I preferred the great bodily harm approach. It was effective. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Put down your guns, it's Weasel Stomping Day! --
