[twitter-dev] Searching for updates since an update by a protected account

[Hwee-Boon Yar]

In order to find updates after a protected account's update, I am
running the following query, setting since_id to the ID of that
update.

http://search.twitter.com/search.json?q=to:simplytweet2&since_id=1297312280

The problem of course is that this query fails [1] since searching
with a since_id value that points to an update  not in the database
always returns 404. This update is from a protected user, so it is not
in the database.

Is there anyway around this? I'm currently incrementing the since_id
by 1 if I get a 404, but it looks like a patch.


[1] -
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/d103746e5c94a166/d4c2a15fd6165cad?lnk=gst&q=since_id+search#d4c2a15fd6165cad

--
Hwee-Boon

[twitter-dev] Re: Searching for updates since an update by a protected account

[Hwee-Boon Yar]

I use a combination of Twitter REST and Search API. The ID for the
message came from the Twitter REST API of the authenticating user or a
friend of his.

--
Hwee-Boon

On Mar 11, 5:08 am, Chad Etzel  wrote:
> If you are using the search API to get the updates, how are you
> getting an update ID from a protected user?
> -Chad
>
>
>
> On Tue, Mar 10, 2009 at 4:31 PM, Hwee-Boon Yar  wrote:
>
> > In order to find updates after a protected account's update, I am
> > running the following query, setting since_id to the ID of that
> > update.
>
> >http://search.twitter.com/search.json?q=to:simplytweet2&since_id=1297...
>
> > The problem of course is that this query fails [1] since searching
> > with a since_id value that points to an update  not in the database
> > always returns 404. This update is from a protected user, so it is not
> > in the database.
>
> > Is there anyway around this? I'm currently incrementing the since_id
> > by 1 if I get a 404, but it looks like a patch.
>
> > [1] -
> >http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> > --
> > Hwee-Boon

[twitter-dev] Re: Finding tweet by id only

[Hwee-Boon Yar]

I built it into an iPhone client, blogged about it here -
http://motionobj.com/blog/the-conversation-view-in-simplytweet. Is
such a thing in wide demand?

--
Hwee-Boon

On Mar 18, 11:18 am, TjL  wrote:
> This seems like it would be a fairly easy project to do, something like
>
> http://tweetbynumber.com/0
>
> Look up the tweet, see if it exists, if it does, display it (and cache it)
>
> Assuming that we eventually get a way to search for replies, you could
> display those too.
>
> Is Twitter Inc going to add this?
>
> If not, is someone else working on it?
>
> TjL

[twitter-dev] Re: Reserved usernames

[Hwee-Boon Yar]

If that's the problem you are trying to solve, just make a API call to
retrieve the user information for xxx.

--
Hwee-Boon

On Mar 18, 11:22 am, "jim.renkel"  wrote:
> Richard,
>
> I think the problem you're trying to solve here is: given a URL of the
> formhttp://twitter.com/xxx, is xxx a valid twitter username? (At
> least that's a problem that I'm trying to solve for an application I'm
> developing.).

>
> > Is this everything, or have I missed anything?
>
> > Richard

[twitter-dev] What does "following" in user information do?

[Hwee-Boon Yar]

So if I do, http://twitter.com/users/show/XXX.xml

What does the value of following (true/false) mean? I tried
authenticating as someone that both follows and is followed by XXX and
yet the value of following is still false.

Docs say: boolean indicating if a user is following a given user

Any thoughts?

--
Hwee-Boon

[twitter-dev] Re: What does "following" in user information do?

[Hwee-Boon Yar]

I'm seeing it in XML though. The bugs are for JSON format.

--
Hwee-Boon

On Mar 21, 12:06 am, Doug Williams  wrote:
> Looking at the issues, this is known [1], [2]. Add a star to show it's a
> priority:
>
> 1.http://code.google.com/p/twitter-api/issues/detail?id=157
> 2.http://code.google.com/p/twitter-api/issues/detail?id=99
>
> Doug Williams
> Twitter API Supporthttp://twitter.com/dougw
>
> On Fri, Mar 20, 2009 at 11:54 AM, Pleasant Software <
>
>
>
> pleasantsoftw...@googlemail.com> wrote:
>
> > Same problem here. I guess it's a bug.
>
> > Eberhard
>
> > On Mar 20, 9:40 am, Hwee-Boon Yar  wrote:
> > > So if I do,http://twitter.com/users/show/XXX.xml
>
> > > What does the value of following (true/false) mean? I tried
> > > authenticating as someone that both follows and is followed by XXX and
> > > yet the value of following is still false.
>
> > > Docs say: boolean indicating if a user is following a given user
>
> > > Any thoughts?
>
> > > --
> > > Hwee-Boon

[twitter-dev] Re: friends_timeline and following

[Hwee-Boon Yar]

This:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/bba8bbd5176fbb24/4a9cb5d5780da976?hl=en&lnk=gst&q=following+hwee+boon#4a9cb5d5780da976
and http://code.google.com/p/twitter-api/issues/detail?id=157.
Supposed to be fixed? (I haven't verified. I stopped relying on it).

On Apr 4, 2:54 am, Doug Williams  wrote:
> I vaguely remember something, too, but my queries through the archives
> and issues list were fruitless. If this is replicatable, then we
> should open an issue. I'd be curious if it's still an issue once the
> big-users-everywhere change from April 1 propagates fully.
>
> @SuNcO: can you confirm you can recreate this at will? If so, can you
> open a new issue?
>
> Thanks,
> Doug Williams
> Twitter API Supporthttp://twitter.com/dougw
>
>
>
> On Fri, Apr 3, 2009 at 11:50 AM, Chad Etzel  wrote:
>
> > I could swear that this topic has been discussed recently and that
> > there was an issue for it, but I'm not finding anything... google is
> > not so good at searching code snippets.
> > -chad
>
> > On Fri, Apr 3, 2009 at 2:46 PM, Abraham Williams <4bra...@gmail.com> wrote:
> >> Do so searches on the issue tracker and if you don't find anything open an
> >> issue:http://code.google.com/p/twitter-api/issues/list
>
> >> On Fri, Apr 3, 2009 at 12:59, SuNcO  wrote:
>
> >>> Nop, is not new. When that happend yesterday, i check via web and i
> >>> appear on his following list (and he on my following list, else how
> >>> can i see that update)
>
> >>> Going to check now again (at night)
>
> >>> On 3 abr, 00:20, Abraham Williams <4bra...@gmail.com> wrote:
> >>> > Is it a user you recently started following? I may be a caching issue
> >>> > and
> >>> > the real value has not propagated yet.
>
> >>> > On Fri, Apr 3, 2009 at 01:19, SuNcO  wrote:
>
> >>> > > Post before but after 30 minutes i can't see the msg, so i post again
>
> >>> > > ---
>
> >>> > > Im new on developing a twitter app. The first thing that i use is :
> >>> > >http://twitter.com/statuses/friends_timeline.xml
>
> >>> > > It returns me 20 msgs in xml format
>
> >>> > > One of those msgs have false
>
> >>> > > But.. i follow that user and that user is following me. What happend ?
>
> >>> > --
> >>> > Abraham Williams | Hacker |http://abrah.am
> >>> > @poseurtech |http://the.hackerconundrum.com
> >>> > Web608 | Community Evangelist |http://web608.org
> >>> > This email is: [ ] blogable [x] ask first [ ] private.
> >>> > Sent from Madison, Wisconsin, United States
>
> >> --
> >> Abraham Williams | Hacker |http://abrah.am
> >> @poseurtech |http://the.hackerconundrum.com
> >> Web608 | Community Evangelist |http://web608.org
> >> This email is: [ ] blogable [x] ask first [ ] private.
> >> Sent from New York, NY, United States

[twitter-dev] count parameter not correctly used for /direct_messages.format

[Hwee-Boon Yar]

wget http://id:passw...@twitter.com/direct_messages.xml?count=15
grep " | wc -l

prints 9.


Ditto for other numbers.

--
Hwee-Boon

[twitter-dev] Re: Public Timeline Frozen

[Hwee-Boon Yar]

Hmm.. when did the Streaming API come about? I see Firehose mentioned
in there, OK that's known. What's Spritzer? (I read the description
and tested it).

-
Hwee-Boon

On May 8, 12:39 am, John Kalucki  wrote:
> Matt,
>
> As Doug mentioned, we're working on fixing the public timeline. I hope
> we can get that updating again shortly.
>
> As a workaround, you might consider an early migration to the
> Streaming API. The /spritzer resource should have about the same
> amount of data, but in an easier to consume format. So far the
> availability has been very good, and the latency very low.
>
> -John
>
> On May 7, 6:01 am, mattarnold1977  wrote:
>
>
>
> > I just checked the log on my server and noticed that the public time
> > line has been putting out the same status information since around 5
> > o'clock yesterday.  Is this a known issue?
>
> > -Matt

[twitter-dev] Re: Streaming API Terms Of Service change - multiple simultaneous logins discouraged

[Hwee-Boon Yar]

Oh god. Please share where is this twitter-announce list?

--
Hwee-Boon

On May 10, 12:51 pm, Jesse Stay  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  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: API limit confusion

[Hwee-Boon Yar]

It's working like you want it to be.

In other words, you have a web app running on a single server with a
single IP. You make authenticated requests using each user's account.
If your IP is whitelisted, the calls go towards your 20k limit, if it
is not whitelisted, it goes against the current 150 limit for the
respective accounts. That's what it means by "IP whitelisting takes
precedence to account rate limits".

--
Hwee-Boon

On Jul 23, 3:02 pm, srikanth reddy  wrote:
> On Thu, Jul 23, 2009 at 12:07 PM, Abraham Williams <4bra...@gmail.com>wrote:
>
> <<
> Each user and each IP has 150 calls/hour. If five applications (desktop or
> web) are making calls on behalf of a single user or IP they count against
> the same 150. Rate limiting has no connection to applications.
>
>
>
> Agreed. i have no issues with desktop apps as each user owns one (in which
> case ip/user does not matter and am pretty happy with 150 limit).
>
> But i am trying to understand this ip limit for web apps
>
> The  whole confusion is regarding this statement 
> inhttp://apiwiki.twitter.com/Rate-limiting
>
> "IP whitelisting takes precedence to account rate limits. *GET requests from
> a whitelisted IP address made on a user's behalf will be deducted from the
> whitelisted IP's limit, not the users*. Therefore, IP-based whitelisting is
> a best practice for applications that request many users' data"
>
> If the above holds true my consumer web app could end up serving very few
> authenticated users. As you said it should be the other way.
> May be some one who has developed and encountered this problem with a webapp
> (with out being whitelisted) can confirm.
>
> Thanks
> Srikanth
>
>
>
>
>
> > On Wed, Jul 22, 2009 at 15:06, srikanth reddy 
> > wrote:
>
> >> @Abraham: Does it mean my consumer app (not Desktop client) cannot serve
> >> more than 150 authorized users/hour(if it is not white listed). It is hard
> >> to believe.
> >> If it is desktop client the 150 limit is understandable.
>
> > Each user and each IP has 150 calls/hour. If five applications (desktop or
> > web) are making calls on behalf of a single user or IP they count against
> > the same 150. Rate limiting has no connection to applications.
>
> >> The blog post says
>
> >> "This limit applies to your Twitter account rather than the applications
> >> which make the calls to the API i.e. you have 100 API calls per hour in
> >> total regardless of which Twitter applications you use - it is NOT 100 API
> >> calls per application"
>
> >> As you said
>
> >> "Also it used to be that user requests from a whitelisted IP would
> >> reflect on the users limit unless they had hit their rate limit at which
> >> point it would count against the IP."
>
> >> its probably first user and then IP.
>
> > Yes. User then IP.
>
> >> " POST request have their own limits"
> >> yes i do not mean infinite calls but my consumer app should be able to get
> >> more than 20k request tokens
>
> >> Thanks for your time. Really helpful
> >> Srikanth
>
> >> On Wed, Jul 22, 2009 at 7:41 PM, Abraham Williams <4bra...@gmail.com>wrote:
>
> >>> In your first email you said "When I check an oAuth'd user's rate limit,
> >>> he also seems gets 2 API hits." so I'm not sure what you are seeing.
> >>> Also it used to be that user requests from a whitelisted IP would reflect
> >>> on the users limit unless they had hit their rate limit at which point it
> >>> would count against the IP. I'm not sure if it still works this way 
> >>> though.
> >>> Abraham
>
> >>> On Wed, Jul 22, 2009 at 08:43, sjespers  wrote:
>
>  @Abraham: If that were true then calling rate_limit_status should give
>  the same result... which it doesn't!
>
>  On Jul 22, 3:26 pm, Abraham Williams <4bra...@gmail.com> wrote:
>  > I recommend that you both read:
> http://apiwiki.twitter.com/Rate-limiting
>
>  > Serge: If you have an IP that is white listed all applicable calls
>  from that
>  > IP will count against the 2 limit.
>
>  > Srikanth: That blog post says that twitter.com has no limit. It says
>  nothing
>  > about anybody else not having a limit. The 20k is for GET requests
>  however
>  > POST request have their own limits.
>
>  > Abraham
>
>  > On Wed, Jul 22, 2009 at 03:07, srikanth reddy <
>  srikanth.yara...@gmail.com>wrote:
>
>  > > Hi
>  > > I am also looking for this. The following post says there is no
>  limit on
>  > > calls from application
>
>  > >http://tweetdeck.posterous.com/what-does-rate-limit-exceeded
>
>  > > Rate limit is applicable on Get methods from ip/client.
>  > > Can someone confirm if one can make unlimited calls (from an app) to
>  get
>  > > request token? What is this 2 limit? Is it for GET calls for
>  authorized
>  > > client/ip
>
>  > > Regards
>  > > Srikanth
>
>  > > On Wed, Jul 22, 2009 at 1:24 PM, sjespers 
>  wrote:
>
>  > >> Hi there,
>
>  > >> I am a little 

[twitter-dev] Re: API limit confusion

[Hwee-Boon Yar]

Isn't this what I said?

--
Hwee-Boon

On Jul 24, 2:36 pm, srikanth reddy  wrote:
> @jim.renkel. Thanks a ton. I think now it is clear.
>
> < requests per hour, independent of any other users of that site or *any
> other uses of the twitter API at other sites by that user *>>
>
> probably this is what they mean by
>
> *"IP whitelisting takes precedence to account rate limits*. *GET requests
> from a whitelisted IP address made on a user's behalf will be deducted from
> the whitelisted IP's limit, not the users*."
>
> If the IP limit  is for the consumer then it will lead to denial of service
> attacks.
> This is how we wanted it to work.
>
> Srikanth
>
>
>
> On Fri, Jul 24, 2009 at 12:52 AM, jim.renkel  wrote:
>
> > My experience with this is, I think, a little bit different than what
> > you describe.
>
> > It appears to me that each user of a white-listed site gets 20k
> > requests per hour, independent of any other users of that site or any
> > other uses of the twitter API at other sites by that user.
>
> > I didn't think this was what twitter intended and reported it as a bug
> > (See:http://code.google.com/p/twitter-api/issues/detail?id=617), but
> > the twitter folk said "Yup, working as intended".
>
> > After you log in athttp://twxlate.com, the site reports rate limit
> > information on every page view, so you can see how this works there.
>
> > Comments expected and welcome.
>
> > Jim Renkel
>
> > On Jul 23, 3:48 am, jmathai  wrote:
> > > > In other words, you have a web app running on a single server with a
> > > > single IP. You make authenticated requests using each user's account.
> > > > If your IP is whitelisted, the calls go towards your 20k limit, if it
> > > > is not whitelisted, it goes against the current 150 limit for the
> > > > respective accounts. That's what it means by "IP whitelisting takes
> > > > precedence to account rate limits".
>
> > > I don't believe that is true.  If your web app is running on a
> > > whitelisted IP then you get up to 20k GET calls per hour.  POST
> > > requests (status or DM) are counted against the user being
> > > authenticated.  You CANNOT retrieve a user's rate limit status.

[twitter-dev] Re: Platform downtime is expected

[Hwee-Boon Yar]

I was trying to be patient with this, but seeing that no one is
complaining, I'm afraid I might be alone here.

One of SimplyTweet's server had not been able to access the API *at
all*. Even /rate_limit_status (nothing to do with OAuth) timeout every
time. Is this expected? No response when I tweeted @twitterapi, as
usual.

wget "http://twitter.com/account/rate_limit_status.xml?
screen_name=hboon"


--
Hwee-Boon


On Aug 16, 4:40 pm, Costa Rica  wrote:
> Hello
> I am perceiving search API downtime as well
>
> http://search.twitter.com/search?q=Indonesiareturns results, but the
> XML, ATOM, JSON are returning me a blank page...
> TCI
>
> On Aug 15, 12:08 pm, Doug Williams  wrote:
>
>
>
> > Hi all --If you have been monitoring our status blog [1] or been to
> > Twitter.com today you have noticed that we are once again experiencing
> > problems due to external causes. The issues causing the downtime require
> > that we once again take measures to bring the site back online.
>
> > The first step our operations team must take will likely cause API downtime,
> > especially affecting OAuth. We apologize for the inconvenience and we will
> > work quickly to reduce the impact to the API. We appreciate your patience
> > and I will update you as soon as we know more.
>
> > Thanks,
> > Doug

[twitter-dev] Re: Platform downtime is expected

[Hwee-Boon Yar]

> The API team is actively debugging the OAuth issues as we speak.

This is what worries very much.

I can't even do this without timing out:

curl "http://twitter.com/account/rate_limit_status.xml?
screen_name=hboon"

I have no API access *at all*.

--
Hwee-Boon

[twitter-dev] Re: Platform downtime is expected

[Hwee-Boon Yar]

Can you confirm if OAuth access is the only known issue? I feel silly
repeating the same question over and over again: "Even /
rate_limit_status calls are timing out on my server. I have no API
access *at all*".

--
Hwee-Boon


On Aug 17, 5:21 am, Chad Etzel  wrote:
> We've asked the keeper-o-the-blog to post something to that effect.
> Hopefully it will appear soon.
> -Chad
>
>
>
> On Sun, Aug 16, 2009 at 4:42 PM, Dewald Pretorius wrote:
>
> > Can you at the very least PLEASE publish something on
> > status.twitter.com about the API being down and/or very unresponsive
> > at times, so that I have a link where I can refer my users, so that
> > they can see I am not shitting them?
>
> > Dewald

[twitter-dev] Is favoriting broken?

[Hwee-Boon Yar]

Is favoriting broken?

--
Hwee-Boon

[twitter-dev] account/update_profile API call fails if original screen name has uppercase characters and login don't match exactly

[Hwee-Boon Yar]

I filed this a few weeks ago and the ticket wasn't commented on nor
discussed here, so I replicate it here to bring some attention to it.
It's an obscure bug:

==

Calls to account/update_profile API fails if the original screen name
(the one that was signed up with, eg. "User1", instead of "user1") has
uppercase characters and login don't match exactly (e.g "user1" and
not "User1").

Most, if not all other Twitter API calls, including the authenticating
call is case-insensitive. But if the user has a screen name which has
at least an uppercase character, account/update_profile will fail
unless the authenticated screen name is spelled exactly the same.

http://code.google.com/p/twitter-api/issues/detail?id=926

[twitter-dev] Re: Alert: "Twitpocalypse II" coming Friday, September 11th - make sure you can handle large status IDs!

[Hwee-Boon Yar]

May I know when and where was it mentioned that it will be
artificially increased this coming Friday?

--
Hwee-Boon

On Sep 10, 2:49 am, Alex Payne  wrote:
> As mentioned previously, the Twitter operations team willartificially
> increase the maximum status ID to 4294967296 this coming Friday,
> September 11th. This action is part of routine database upgrades and
> maintenance.
>
> If your Twitter API application stores status IDs, please be sure that
> your datastore is configured to handle integers of that size. Thanks.
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Alert: "Twitpocalypse II" coming Friday, September 11th - make sure you can handle large status IDs!

[Hwee-Boon Yar]

One suggestion: similar to API changes, it seems more appropriate that
if you want to force it, to do it earlier in the week, starting
Monday, rather than Friday. That leaves enough resources and hands to
stock up water and non-perishable goods rather than on a Friday.

--
Hwee-Boon


On Sep 12, 12:27 am, Ryan Sarver  wrote:
> To give everyone an update --
>
> We have been able to work with our operations team to delay the forced
> update until around September 21st or 22nd (over a week away). Since
> this twitpocalypse is based on the tweet count, it is impossible to
> predict exactly when it will happen and therefore we can only make
> projections based on current usage and possible spikes. With that
> being said, it *could* happen as early as Sept 16th (Wednesday), so
> please start updating your applications now to handle the change. We
> will be able to give you better estimates as the event moves closer
> and we will be sure to update the list when we know the exact time of
> the update.
>
> Let us know if you have any questions and be sure to stock up on water
> and non-perishable goods :)
>
> Ryan
>
>
>
> On Thu, Sep 10, 2009 at 9:10 AM, Ivan Kirigin wrote:
>
> > Call me crazy, but I store any data from a 3rd party in strings.
> > Typically, I used a text blob to store some serialized object (like
> > json or a python pickle) which maximizes flexibility. For the tweet
> > id, I think I used 64 chars.
>
> > In about 10 years, after I've cleared all the other higher priority
> > and more impactful optimizations, I might think about dealing with
> > this again.
>
> > Ivan
> >http://kirigin.com
>
> > On Sep 10, 5:48 am, JDG  wrote:
> >> and if they are, just store the twos complement of the ID in the DB and do
> >> the math when you retrieve if it's negative. :)
>
> >> On Thu, Sep 10, 2009 at 00:12, Rob Ashton  wrote:
> >> >  I've always just stored as 64bit integers, I'd assumed that 32bit
> >> > wouldn't be enough.
>
> >> > Now, if it goes above 64bit then I'm screwed, because neither my language
> >> > or database have built in support for that! :P
>
> >> >  *From:* JDG 
> >> > *Sent:* Thursday, September 10, 2009 4:21 AM
> >> > *To:* twitter-development-talk@googlegroups.com
> >> > *Subject:* [twitter-dev] Re: Alert: "Twitpocalypse II" coming Friday,
> >> > September 11th - make sure you can handle large status IDs!
>
> >> > if you were on signed32 you'd have had a problem a long time ago. not 
> >> > quite
> >> > sure why people haven't just taken to treating/storing as strings -- sure
> >> > there's a bit more overhead mem/storage-wise, but you don't have to 
> >> > change
> >> > your code every few months.
>
> >> > On Wed, Sep 9, 2009 at 16:45, Joseph Cheek  wrote:
>
> >> >> Twitter is in league with Al Qaida!  You heard it first here, folks!
>
> >> >> Ok, seriously, this message I wrote wasn't worth the electrons it took
> >> >> to transmit it...  let's see if I can increase the s2n ratio:
>
> >> >> 4294967296, that an unsigned 32-bit int?  ok, fair enough.  i know some
> >> >> of my apps use signed 64bit ints, but i'm not sure about the db... will
> >> >> need to check... might be signed32...
>
> >> >> Joseph Cheek
> >> >> jos...@cheek.com,www.cheek.com
> >> >> twitter:http://twitter.com/cheekdotcom
>
> >> >> Nicholas Moline wrote:
> >> >> > And nobody thought about the significance of accelerating anything
> >> >> > called a *pocolypse to be on the anniversary of a date that thousands
> >> >> > died in a terrorist attack Tactful Twitter... Real Tactful
>
> >> >> > On Wed, Sep 9, 2009 at 1:00 PM, Alex Payne  >> >> > <mailto:a...@twitter.com>> wrote:
>
> >> >> >     Sorry, an error in phrasing. It was previously mentioned that this
> >> >> >     change was pending. We had not previously announced a date for the
> >> >> >     change.
>
> >> >> >     Normally, we prefer to provide more advance notice where possible,
> >> >> but
> >> >> >     I'm letting you all know immediately after our operations team
> >> >> >     informed me that it was necessary to make this change on Friday.
>
> >> >> >     On Wed, Sep 9, 2009 at 12:13, Hwee-B

[twitter-dev] Re: statuses/mentions vs search/screenname

[Hwee-Boon Yar]

Along the same line, updates from accounts considered spamming
wouldn't be included in search results too.

--
Hwee-Boon

On Sep 17, 12:07 am, JDG  wrote:
> I believe that search does not return statuses of protected users (even when
> authenticated, though I may be wrong and should be corrected if I am). In
> that case, yes, you could potentially receive fewer results than
> statuses/mentions.
>
> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  wrote:
>
> > Quick q:
>
> > is there any time that a search for a screenname won't return every
> > tweet that statuses/mentions will?  i can see that it would return more,
> > but will it ever return less?
>
> > Joseph Cheek
> > jos...@cheek.com,www.cheek.com
> > twitter:http://twitter.com/cheekdotcom
>
> --
> Internets. Serious business.

[twitter-dev] Re: Deleting a Retweeted Tweet

[Hwee-Boon Yar]

On Sep 24, 2:16 pm, Josh Roesslein  wrote:
> This could be done by just
> posting a second
> tweet with the reply parameter pointing at the retweet.

With the current way RT works (without the RT API) and at least as of
a month ago, making RTs a reply makes it limited to people who follow
both the sender and the original author (since it's a reply). This
greatly diminishes the point of retweeting and was the reason why I
stopped setting the reply to ID for RTs in SimplyTweet.

--
Hwee-Boon

[twitter-dev] XML API returning old DM timelines

[Hwee-Boon Yar]

I'm reposting a support email I sent to API support to see if anyone
else is facing the same issue:

1. Some users of SimplyTweet (iPhone app) are receiving old versions
of the DM timeline.
2. On a related note, I seem to be having the same issue with
SimplyTweet's servers (for push notification support) using since_id
too, where I get timelines including id < X (note: older) when I set
since_id = X

This seems to have started these 2 days. I have personally seen issue
1 at least twice on my iPhone (Singapore). As for issue 2, the servers
are hosted with Slicehost.

Is this a known issue?

--
Hwee-Boon

[twitter-dev] Re: XML API returning old DM timelines

[Hwee-Boon Yar]

Which one?

On Oct 19, 5:40 pm, Leon Spencer  wrote:
> Hi.
>
> I think there is a similar post in the discussion. A Twitter support person 
> appears to have responded directly to it.
>
> Leon
>
> ________
> From: Hwee-Boon Yar 
> To: Twitter Development Talk 
> Sent: Mon, October 19, 2009 2:36:37 AM
> Subject: [twitter-dev] XML API returning old DM timelines
>
> I'm reposting a support email I sent to API support to see if anyone
> else is facing the same issue:
>
> 1. Some users of SimplyTweet (iPhone app) are receiving old versions
> of the DM timeline.
> 2. On a related note, I seem to be having the same issue with
> SimplyTweet's servers (for push notification support) using since_id
> too, where I get timelines including id < X (note: older) when I set
> since_id = X
>
> This seems to have started these 2 days. I have personally seen issue
> 1 at least twice on my iPhone (Singapore). As for issue 2, the servers
> are hosted with Slicehost.
>
> Is this a known issue?
>
> --
> Hwee-Boon

[twitter-dev] Re: XML API returning old DM timelines

[Hwee-Boon Yar]

Ah. I saw that. No, that's search. Doesn't look related (but it could
be of course).

--
Hwee-Boon


On Oct 19, 7:34 pm, Leon Spencer  wrote:
> I could be wrong. This one says old messages in general. Doesn't mention DMs. 
> But it refers to a help post.
>
> http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> Let me know if this helps.
>
> Leon
>
> ________
> From: Hwee-Boon Yar 
> To: Twitter Development Talk 
> Sent: Mon, October 19, 2009 4:30:42 AM
> Subject: [twitter-dev] Re: XML API returning old DM timelines
>
> Which one?
>
> On Oct 19, 5:40 pm, Leon Spencer  wrote:
>
>
>
> > Hi.
>
> > I think there is a similar post in the discussion. A Twitter support person 
> > appears to have responded directly to it.
>
> > Leon
>
> > 
> > From: Hwee-Boon Yar 
> > To: Twitter Development Talk 
> > Sent: Mon, October 19, 2009 2:36:37 AM
> > Subject: [twitter-dev] XML API returning old DM timelines
>
> > I'm reposting a support email I sent to API support to see if anyone
> > else is facing the same issue:
>
> > 1. Some users of SimplyTweet (iPhone app) are receiving old versions
> > of the DM timeline.
> > 2. On a related note, I seem to be having the same issue with
> > SimplyTweet's servers (for push notification support) using since_id
> > too, where I get timelines including id < X (note: older) when I set
> > since_id = X
>
> > This seems to have started these 2 days. I have personally seen issue
> > 1 at least twice on my iPhone (Singapore). As for issue 2, the servers
> > are hosted with Slicehost.
>
> > Is this a known issue?
>
> > --
> > Hwee-Boon

[twitter-dev] Re: linespaces / whitespace being removed: bug or feature?

[Hwee-Boon Yar]

I've observed the same behavoir at least 10 hours ago and still seeing
it now.

--
Hwee-Boon

On Oct 21, 3:57 am, TjL  wrote:
> On Tue, Oct 20, 2009 at 2:11 PM, Michael Ivey  wrote:
> > As an aside; please don't bump threads on this list.
>
> As an aside, how about someone answers the question rather than just
> getting pissy at people who are trying to figure out how a change is
> going to effect products they're building around Twitter's API?
>
> If Twitter is getting rid of whitespace, that means I can strip out a
> bunch of code in certain places.
>
> I'd like someone to comment on this officially.
>
> TjL

[twitter-dev] Very slow response with API from Slicehost

[Hwee-Boon Yar]

I have been having these very slow API response running on Slicehost
(most of the time way more than 2-3 seconds) for the past 2 days. Is
this something being actively worked on?

It's becoming really painful that people are telling me my app doesn't
work.

--
Hwee-Boon

[twitter-dev] Re: Very slow response with API from Slicehost

[Hwee-Boon Yar]

2-5 secs for a /help/test.format or getting DM/Mention timeline is
certainly not OK.

And thanks for confirming I'm not alone.

--
Hwee-Boon

On Oct 22, 12:00 am, Josh Roesslein  wrote:
> I just did a few tests on my slicehost VPS and the delay seems okay
> here. 2-5 seconds range which is about the same I'm getting locally.
>
> Are all API endpoints slow for you or just a select few?
>
> Josh
>
>
>
> On Wed, Oct 21, 2009 at 10:53 AM, Hwee-Boon Yar  wrote:
>
> > I have been having these very slow API response running on Slicehost
> > (most of the time way more than 2-3 seconds) for the past 2 days. Is
> > this something being actively worked on?
>
> > It's becoming really painful that people are telling me my app doesn't
> > work.
>
> > --
> > Hwee-Boon

[twitter-dev] Re: Very slow response with API from Slicehost

[Hwee-Boon Yar]

On Oct 22, 12:05 am, RandyC  wrote:
>  I'm surprised more people aren't talking
> about this unless we're the only ones affected.

Me too. Which is why I'm posting it here. No one else seems to be
complaining. I was beginning to wonder I was alone.

--
Hwee-Boon

[twitter-dev] Re: Very slow response with API from Slicehost

[Hwee-Boon Yar]

Like I have mentioned privately to someone:

"Can I then make a next best suggestion that is most easy to implement
and yet effective? It has been suggested more than once. Post an
update to status.twitter.com. Even a short message. Give us something
to retweet, to forward to users. If you want to know the impact on 3rd
party developers, go to iTunes App Store on your iPhone (I assume you
use one) and read the top few reviews for SimplyTweet. They mention
performance problems and loading errors of SimplyTweet. . Tell
me how this doesn't hurt us?

Do you not agree that not posting updates under situations like this
(where you know it has been under heavy load for a couple of days)
reflects policy rather than lack of 3rd party developer support
resources? If fact, I'll be blunt and say that this policy directly
suggests to me, as a 3rd party developer, that Twitter doesn't care
about us and is even letting us help shield Twitter from user
complaints."

--
Hwee-Boon

On Oct 22, 12:29 am, Michael Steuer  wrote:
> No, seeing the same since Saturday. @rsarver said on Sunday morning he would
> post information to the group once they knew what was causing all this, but
> I guess 4 days later they still don't know, as we haven't heard anything...
>
> On 10/21/09 9:05 AM, "RandyC"  wrote:
>
>
>
>
>
> > I have been seeing enormous numbers of 502's and 500's for API calls
> > from Qwest DSL business, Rackspace, and Amazon Cloud instances since
> > Saturday through today.  Working through the UI to log into accounts
> > is equally painful with constant fail whales after two to three
> > attempts.  Seems like a couple of bad hair days so far and very
> > difficult to get much done.  I'm surprised more people aren't talking
> > about this unless we're the only ones affected.

[twitter-dev] Inconsistency between web and API when viewing account blocking you

[Hwee-Boon Yar]

(S)omeone blocks (Y)ou.

Web
===
If you are logged in as Y and go to http://twitter.com/S, you get no
indication that you are blocked, being able to view S's timeline, etc.

API
===
When accessing S's timeline using /statuses/user_timeline/S.xml
authenticated as Y, however, you get a 401/Not Authorized.

A) Besides 401 having overloaded meanings (wrong credentials. it can
also mean S has been deleted [1]), so we can't tell what is wrong,
B) It is also inconsistent. Should Y be allowed to view S's timeline
(web) or not (API)?


[1] http://code.google.com/p/twitter-api/issues/detail?id=1226
[2] Also reported at http://code.google.com/p/twitter-api/issues/detail?id=1243

--
Hwee-Boon

[twitter-dev] What is the expected behavoir of Retweeting a retweet

[Hwee-Boon Yar]

I did an experiment.

user1 tweets update1
user2 retweets update1 as update2 (a RT, with update1 embedded)
user3 retweets update2, the embedded update is update1 instead of
update2.

I can't find documentation on this. Is this the expected behavoir?

--
Hwee-Boon

[twitter-dev] Are retweets supposed to capture the original tweet as meta in search results or are they supposed to be "plain text"?

[Hwee-Boon Yar]

I tried searching against http://search.twitter.com and the ATOM
search API and found that retweets created using the API appears as
plain text in search results, with no metadata referring to the
original tweet. Is this the expected behavoir? If so, any plans to
make it consistent?

--
Hwee-Boon

[twitter-dev] Inconsistency between JSON and Atom search API

[Hwee-Boon Yar]

This is search results for JSON and Atom call, 10 minutes after the
tweet was sent (timestamp 2009-12-05T03:38:11Z). 0 results for JSON, 1
result for Atom

JSON
===
0 results:

$ curl "http://search.twitter.com/search.json?
q=to:Smoothe_1&since_id=6357863332"

{"results":[],"max_id":6358271161,"since_id":
6357863332,"refresh_url":"?since_id=6358271161&q=to
%3ASmoothe_1","results_per_page":15,"page":1,"completed_in":
0.01,"query":"to%3ASmoothe_1"}


Atom
===
1 result:

$ curl "http://search.twitter.com/search.atom?
q=to:Smoothe_1&since_id=6357863332"


http://base.google.com/ns/1.0"; xml:lang="en-US"
xmlns:openSearch="http://a9.com/-/spec/opensearch/1.1/"; xmlns="http://
www.w3.org/2005/Atom" xmlns:twitter="http://api.twitter.com/";>
  tag:search.twitter.com,2005:search/to:Smoothe_1
  http://search.twitter.com/search?q=to
%3ASmoothe_1" rel="alternate"/>
  http://search.twitter.com/
search.atom?q=to:Smoothe_1&since_id=6357863332" rel="self"/>
  to:Smoothe_1 - Twitter Search
  
  http://search.twitter.com/
search.atom?q=to%3ASmoothe_1&since_id=6359226173" rel="refresh"/>
  2009-12-05T03:38:11Z
  15
  
tag:search.twitter.com,2005:6359226173
2009-12-05T03:38:11Z
http://twitter.com/simplytweet/
statuses/6359226173" rel="alternate"/>
@Smoothe_1 is it still not working? Server side seems ok
though.
@Smoothe_1 is it still not working?
Server side seems ok though.
2009-12-05T03:38:11Z
http://a1.twimg.com/profile_images/
234093666/73_normal.png" rel="image"/>


SimplyTweet
en

  simplytweet (simplytweet)
  http://twitter.com/simplytweet

  


--
Hwee-Boon

[twitter-dev] Re: Basic Auth Deprecation in June

[Hwee-Boon Yar]

On Jan 14, 8:30 am, twittme_mobi  wrote:
> Hello ,
>
> Regarding Basic Auth Deprecation is June

Any where this is announced?

--
Hwee-Boon

[twitter-dev] Re: Basic Auth Deprecation in June

[Hwee-Boon Yar]

Thanks. Hope it's not official. I don't remember reading anything like
that on the 2 lists.

--
Hwee-Boon

On Jan 18, 7:01 pm, Rich  wrote:
> Ryan Sarver said it last last 
> yearhttp://twitter.com/Scobleizer/status/6493268213
>
> On Jan 17, 4:46 am, Hwee-Boon Yar  wrote:
>
>
>
> > On Jan 14, 8:30 am, twittme_mobi  wrote:
>
> > > Hello ,
>
> > > Regarding Basic Auth Deprecation is June
>
> > Any where this is announced?
>
> > --
> > Hwee-Boon

[twitter-dev] Search not working properly for filters

[Hwee-Boon Yar]

curl "http://search.twitter.com/search.atom?q=test%20filter%3Alinks
%20(yfrog)"

returns no results and there are only 3 results on the search page for
the same query:

http://search.twitter.com/search?q=http+filter%3Alinks+%28yfrog%29

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

HTTP status codes

[Hwee-Boon Yar]

Hi there,

I took the chance to test out/verify what HTTP status code I should
handle during the current downtime (GMT+8 3pm 19/Feb/2009). But it
looks like 200 is returned when the docs says it should be 502. Can
anyone verify? Thanks.

[twitter-dev] Re: Deprecating /statuses/public_timeline resource on 4/5/10

[Hwee-Boon Yar]

Is there a reasonable replacement to provide the same functionality in
mobile apps?

--
Hwee-Boon

On Mar 5, 12:04 am, Raffi Krikorian  wrote:
> sorry - its being deprecated as of today.  it is being removed on 5 april
> 2010.  hope that clears up the confusion.
>
> On Thu, Mar 4, 2010 at 6:54 AM, Brian Smith  wrote:
> >  Ryan Sarver wrote:
>
> > This is an announcement that we will be deprecating the *
> > /statuses/public_timeline* resource as of April 5th (4/5/10). Please let
> > us know if there are any major concerns.
>
> > Just to be perfectly clear: is it being deprecated or disabled on that
> > date?
>
> > Thanks,
> > Brian
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi

[twitter-dev] How to register current Basic Auth application as OAuth application

[Hwee-Boon Yar]

My Twitter app runs on iPhone (and has a server side component that
user doesn't directly interact with). It has been running on Basic
Auth for more than a year. I would like to register it as OAuth and
migrated users over, i.e. running both in parallel under end June
since not everyone will update their their version immediately.

When I register an app with the same name, it says the name is already
taken. I presume that's referring to the previous Basic Auth app? (or
someone registered my app name - SimplyTweet).

How should I proceed with this? I sent a support ticket, but one of us
isn't understanding the other. Thanks.

[twitter-dev] Re: How to register current Basic Auth application as OAuth application

[Hwee-Boon Yar]

Thanks Brian,

I have filed a new ticket about the trademark report, as well as using
the email address (same domain as previous ticket) I registered the
app with so it's clearer.

--
Hwee-Boon

On May 18, 12:24 am, Brian Sutorius  wrote:
> Registering a basic-auth source parameter was not the same action as
> registering an application. It is possible that between the time you
> registered the "SimplyTweet" source parameter and now, someone else
> registered an application under the same name. If you own a trademark
> on "SimplyTweet", you can follow the process at the lower half 
> ofhttp://twitter.zendesk.com/entries/18367and our Policy team will be
> happy to help you with this. If not, please follow up on your ticket
> (for privacy reasons) and we'll look into it further.
>
> Thanks!
> Brian Sutorius
>
> On May 15, 10:39 pm, Hwee-Boon Yar  wrote:
>
>
>
> > My Twitter app runs on iPhone (and has a server side component that
> > user doesn't directly interact with). It has been running on Basic
> > Auth for more than a year. I would like to register it as OAuth and
> > migrated users over, i.e. running both in parallel under end June
> > since not everyone will update their their version immediately.
>
> > When I register an app with the same name, it says the name is already
> > taken. I presume that's referring to the previous Basic Auth app? (or
> > someone registered my app name - SimplyTweet).
>
> > How should I proceed with this? I sent a support ticket, but one of us
> > isn't understanding the other. Thanks.

[twitter-dev] Deleting a retweet

[Hwee-Boon Yar]

This is probably so obvious I'm missing it. How do I delete a retweet?

[twitter-dev] Re: Announcing Snowflake

[Hwee-Boon Yar]

So, does this mean (to paraphrase):

IDs will remain sorted *all* the time except when comparing between 2
tweets sent within 1 second apart, the order *might* be reversed. And
therefore, for most Twitter apps, no change is necessary?

--
Hwee-Boon

On Jun 2, 10:00 am, themattharris  wrote:
> Hey everyone,
>
> In March we sent a message to you about upcoming changes to the way
> status IDs are sequenced (http://bit.ly/upcoming-status-id-changes).
> Today we announced Snowflake - the service we will be using to
> generate those new IDs.
>
> It isn't going live yet! We just know a lot of you are concerned about
> how the Tweet IDs are going to affect your applications and wanted you
> to have the chance to familiarize yourself with how Snowflake works.
>
> You can find the a link to the code and read more about Snowflake on
> the Twitter Engineering blog:http://bit.ly/announcing-snowflake
>
> Best,
> Matt

[twitter-dev] Re: lang= Support in Search API

[Hwee-Boon Yar]

I get my list from http://search.twitter.com/advanced.

--
Hwee-Boon

On Jun 3, 10:21 am, Bess  wrote:
> I'd like to confirm the list of language support on Search API b/c I
> couldn't find any documentation in this Google group 
> andhttp://dev.twitter.com.
>
> From my online search developers say it supports only 3 languages:
> English = en
> Japanese = ja
> Spanish = es
>
> From documentation, it refers to wikipedia on ISO 63901 code. However,
> I try many lang parameters with many of them not working or returning
> much results.
>
> http://en.wikipedia.org/wiki/ISO_639-1
>
> These are listed but not supported:
>
> *   French is represented by fr
> *   German is represented by de
> *   Portuguese is represented by pt
> *   Haiti is represented by ht or hat
>
> lang: Optional: Restricts tweets to the given language, given by
> an ISO 639-1 code.
>
> http://search.twitter.com/search.atom?lang=en&q=devohttp://search.twitter.com/search.atom?q=東京大地震&locale=ja
>
> What are the official lang supported? How can we get the latest list?

[twitter-dev] Re: Incorrect Signature for oAuth

[Hwee-Boon Yar]

Since it's GET works and POST, no. 1 reason is to make sure the base
URI in the base signature string is constructed correctly. In your
example, you don't need source= since it's OAuth.

--
Hwee-Boon

On Jun 6, 8:56 pm, rhysmeister  wrote:
> Hi All,
>
> I am having problems identifying what is wrong with converting my app
> to use oAuth. All my GET requests work fine but my POST requests all
> fail with an incorrect signature error. I am adding the oauth
> parameters to the authorisation header of my request. My authorisation
> header is build like below for GET requests (this works);
>
> OAuth
> oauth_timestamp="1234567890",oauth_nonce="xx",oauth_version="1.0",oauth 
> _signature_method="HMAC-
> SHA1",oauth_consumer_key="xx",oauth_token="xx",oauth_signature="xxx 
> xxx"
>
> My POST requests (these don't work);
>
> OAuth
> oauth_timestamp="1234567890",oauth_nonce="xx",oauth_version="1.0",oauth 
> _signature_method="HMAC-
> SHA1",oauth_consumer_key="xx",oauth_token="xx",oauth_signature="xxx 
> xxx"
>
> I get the below error returned...
>
> 
> 
> 
>   /1/statuses/update.xml?source=xx
>   Incorrect signature
> 
>
> Would anyone be able to provide any pointers here?
>
> Cheers,
>
> Rhys

[twitter-dev] Re: link wrapping on the API

[Hwee-Boon Yar]

Are all links going to be wrapped or only long links? If it's the
latter, what's the definition?

1. This affects how we count characters before sending and has quite a
potential to go wrong, since we'll now need to know exactly which
links are going to be wrapped in a tweet.

2. It's also going to be tricky for apps that currently show a live
character count (like SimplyTweet and many other iPhone Twitter apps
and possibly web sites) as users type.

--
Hwee-Boon

On Jun 9, 6:57 am, Raffi Krikorian  wrote:
> hi all.
>
> twitter has been wrapping links in e-mailed DMs for a couple months
> now.
> with that feature, we're trying to protect users against phishing and other
> malicious attacks. the way that we're doing this is that any URL that comes
> through in a DM gets currently wrapped with a twt.tl URL -- if the URL turns
> out to be malicious, Twitter can simply shut it down, and whoever follows
> that link will be presented with a page that warns them of potentially
> malicious content. in a few weeks, we're going to start slowly enabling this
> throughout the API for all statuses as well, but instead of twt.tl, we will
> be using t.co.
>
> practically, any tweet that is sent through statuses/update that has a link
> on it will have the link automatically converted to a t.co link on its way
> through the Twitter platform. if you fetch any tweet created after this
> change goes live, then its text field will have all its links automatically
> wrapped with t.co links. when a user clicks on that link, Twitter will
> redirect them to the original URL after first confirming with our database
> that that URL is not malicious.  on top of the end-user benefit, we hope to
> eventually provide all developers with aggregate usage data around your
> applications such as the number of clicks people make on URLs you display
> (it will, of course, be in aggregate and not identifiable manner).
> additionally, we want to be able to build services and APIs that can make
> algorithmic recommendations to users based on the content they are
> consuming. gathering the data from t.co will help make these possible.
>
> our current plan is that no user will see a t.co URL on twitter.com but we
> still have some details to work through. the links will still be displayed
> as they were sent in, but the target of the link will be the t.co link
> instead. and, we want to provide the same ability to display original links
> to developers. we're going to use the entities attribute to make this
> possible.
>
> let's say i send out the following tweet: "you have to check 
> outhttp://dev.twitter.com!";
>
> a returned (and truncated) status object may look like:
>
> {
>   "text" : "you have to check outhttp://t.co/s9gfk2d4!";,
>   ...
>   "user" : {
>     "screen_name" : "raffi",
>     ...
>   },
>   ...
>   "entities" : {
>     "urls" : [
>       {
>         "url" : "http://t.co/s9gfk2d4";,
>         "display_url" : "http://dev.twitter.com";,
>         "indices" : [23, 43]
>       }
>     ],
>     ...
>   },
>   ...
>
> }
>
> two things to note: the text of the returned status object doesn't have the
> original URL and instead it has a t.co URL, and the entities block now has a
> display_url attribute associated with it. what we're hoping is that with
> this data, it should be relatively easy to create a UI where you replace 
> thehttp://t.co/s9gfk2d4in the text with the equivalent of
>
> http://t.co/s9gfk2d4";>http://dev.twitter.com
>
> this means the user would not see the t.co link, but we all can still
> provide the protection and gather data from the wrapped link. for the
> applications that don't choose to update, the t.co link will be shown (and
> the goal to protect users will be met). i just want to emphasize -- we
> really do hope that you all render the original URL, but please send the
> user through the t.co link.   if you do choose to prefetch all the URLs on a
> timeline, then, when a user actually clicks on one of the links, please
> still send him or her through t.co. We will be updating the TOS to require
> you to check t.co and register the click.
>
> related to this: the way the Twitter API counts characters is going to
> change ever so slightly. our 140 characters is now going to be defined as
> 140 characters after link wrapping. t.co links are of a predictable length
> -- they will always be 20 characters. after we make this live, it will be
> feasible to send in the text for a status that is greater than 140
> characters. the rule is after the link wrapping, the text transforms to 140
> characters or fewer. we'll be using the same logic that is in
> twitter-text-rb to figure out what is a URL.
>
> look for an update to dev.twitter.com where we'll have a best practices
> document on how to use these t.co links.
>
> what's the timeline?  "soon" we'll enable this on @twitterapi, @rsarver,
> @raffi, and a few other test accounts so you all have live data to play
> with.  on the timescale

[twitter-dev] Re: link wrapping on the API

[Hwee-Boon Yar]

But if apps don't update and user sends a tweet which is just below
140 characters say, 139, and which contain a link(s) shorter than 19
(or is it 20) characters will mysteriously fail. The user will wonder
why the app doesn't let them send the tweet when their app clearly
says it's still within 140 characters, because Twitter is now counting
the longer 19/20 character t.co link.

Is this considered a rare scenario?

--
Hwee-Boon

On Jun 9, 12:18 pm, John Kalucki  wrote:
> Apps that don't update will continue to work, they will just display
> something different than they do now.

[twitter-dev] Re: Python Twitter

[Hwee-Boon Yar]

See 
http://code.google.com/p/oauth-python-twitter/source/browse/trunk/oauthtwitter.p
y?r=6 which extends python-twitter to include OAuth calls. I added a
method at a fork at http://github.com/hboon/oauthtwitter/ to include
the XAuth token exchange call.

--
Hwee-Boon

On Jun 13, 10:39 am, pythonista  wrote:
> Hello,
>  I am using the simplegeo fork of python-oauth2, and it is working
> fine.
>
> However, I then realize it doesn't contain API calls to actually send
> tweets.
>
> Anyone know of a particular Api wrapper that has updated its code, so
> that calls are made using the token/token secret that is now
> mandatory, or will be this month ?
>
> http://code.google.com/p/python-twitter/doesn't seem to have been
> updated yet for making calls via oauth
>
> Thanks.