[twitter-dev] RETRY_AFTER header for Search API
Hey Twitter API devs, We're working on daemons to poll the search API, and we want to make sure that our code will behave correctly when it encounters a RETRY_AFTER header. We think our code should work correctly, but we'd like to be able to test it with a real RETRY_AFTER header. Could you add the option for us to add a RETRY_AFTER=X parameter to the HTTP request that will force your servers to return a RETRY_AFTER header of X seconds, so that we can easily test our code and then remove it? Thanks.
[twitter-dev] Re: Regex for @replies
Hey Craig,
We found an addition to this. Your regex is great, but it doesn't
limit the length of screen names. Twitter doesn't allow signups
greater than 15 chars (but in tweets, it will actually link up to 20
chars).
So, @abcdefghijklmnopqrstuvwxyz will be linked out to
@abcdefghijklmnopqrst
\...@[\w\d_]{1,15}
This also works in Ruby.
-- Tim
On May 12, 2:01 pm, ericdoesdot...@gmail.com
ericdoesdot...@gmail.com wrote:
Hi Everyone,
In .NET, I use the regex: \...@[\w\d_]+
This pattern exhibits the behavior described by Doug -- it finds the
mentions @bob, @BOB, @bob and -...@bob, but not _...@bob and h...@bob.
I sent the following tweet:
`...@a ~...@a !...@a @@a #...@a $...@a %...@a ^...@a @a *...@a (@a )@a
_...@a +...@a -...@a =...@a [...@a
{...@a ]...@a }...@a \...@a |@a ;@a :@a '@a @a ,@a @a @a @a /@a ?...@a
a...@a 1...@a
Twitter and my pattern both did not match _...@a and a...@a and 1...@a.
On May 12, 8:13 am, CaMason stasisme...@googlemail.com wrote:
It looks like they're simply applying this regex as a test:
(?![\w])@username(?![\w])
Thus, if a character on either side is not (a-z, A-Z, 0-9, _) then it
is a mention. any 'word' character (a-z, A-Z, 0-9, _) on either side
of '@screenname' causes the mention to fail.
(I hope I got the regex explanation correct!).
-Craig
On May 12, 12:33 pm, hjb ha...@heatonmoor.com wrote:
@Doug,
Is this behavour likely to remain? ( I noticed that @replies and -
@replies are successful )
That is to say, I'm sure @replies will work at some point via sms, but
can we rely on the fact that _...@replies do not? Is this related to
there being any chance of it being an email address?
Thanks,
Harry
On May 11, 6:26 pm, Doug Williams d...@twitter.com wrote:
In my test posts @dougw and @DOUGW worked as mentions. t...@dougw and
_...@dougw were not included as mentions.
Thanks,
Doug
--
Doug Williams
Twitter Platform Supporthttp://twitter.com/dougw
On Mon, May 11, 2009 at 10:16 AM, CaMason
stasisme...@googlemail.comwrote:
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- Hide quoted text -
- Show quoted text -
[twitter-dev] Re: Deprecation of the email parameter for users/show
Seconding this. On Apr 3, 4:51 am, Todd Sampson toddsampson2...@gmail.com wrote: If you are going to deprecate this method, can you at least return a user not found error as opposed to returning user twitter.com/show? I have received numerous complaints that users we lookup are being assigned to user show and their TonsOfWeed.com website -- which for obvious reasons is not the way to handle a deprecated function. - Todd On Apr 2, 9:00 pm, John Sampson j...@johnasampson.com wrote: Thank you for the clarity and for putting greater detail on the deprecation of user/show (find by email). I completely agree to Twitter wanting to protect its user's privacy. I'd like to think that the value created by whitelisted applications is far greater than the pain being caused by non-whitelisted api users. I hope that a speedy solution can be found for these spammers. Much of my concern I'd previously mentioned on ticket #353 -http://code.google.com/p/twitter-api/issues/detail?id=353#c8. To be clear, this does break the Twitter integration with our Firefox extension (which I consider the most valuable portion of our ext), surfacing information for user with screen name show rather than the person you are connecting with keyed off email. Additionally, workflow need be re-authored in our other apps that have leveraged this method to date. Hoping I can be of further assistance in returning this method to the production API. John Sampsonhttp://zentact.com On Apr 2, 5:59 pm, Doug Williams d...@twitter.com wrote: For a few days, the users/show method offered look up based on a user's email address. So short-lived was its documented availability that we removed it without much fanfare. This thread [1] has mention of this deprecation. Recently, there has been quite a bit of discussion on this feature's reinstatement on and off the list. Issue 353 [2] covers this request. The use of the method was largely as intended; people were discovering account connections based email addresses. This made integration with other networks and applications trivial. However, there was a significant amount of traffic that was using this parameter for evil. In either case, the adoption was minimal (we did not receive a complaint that the deprecation completely broke someone's application). The rationale for deprecation was to protect our users' privacy. We do realize the large amount of value that this parameter creates for application developers. However at this time, we are working to identify a solution for the spammers that caused the deprecation. One suggestion is to grant trusted applications access to this parameter. Since our answer to trusting applications is OAuth and it is still in beta, we will not be able to devote the resources necessary to bring this parameter back at this time. If you are developing an application that could benefit from an email-based lookup, please star the issue [2] accordingly. 1.http://groups.google.com/group/twitter-development-talk/browse_thread... 2.http://code.google.com/p/twitter-api/issues/detail?id=353 Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw
