[twitter-dev] Re: Streaming API Client DNS TTL issue

[M. Edward (Ed) Borasky]

I'm using the command-line "curl" as a client - will it do this, or do
I need to go to a lower-level library-based connection strategy?

On Dec 29, 9:33 am, John Kalucki  wrote:
> I've noticed a handful of Twitter Streaming API clients that are not
> honoring the DNS Time To Live (TTL). If your client is currently
> connected to 128.121.146.231, you certainly have an issue with
> ignoring the TTL. If you have restarted your client in the last few
> weeks, but are connected to another IP address, you may or may not
> have this issue. Clients ignoring DNS TTL will be subject to
> unpredictable outages as we shift load between clusters.
>
> In any case, the prudent developer would test the client stack against
> a test DNS record and validate that the TTL is honored correctly.
>
> I added the following to the Wiki:
>
> "
> Test that your client process honors the DNS Time To live (TTL). Some
> stacks will cache a resolved address for the duration of the process
> and will not pick up DNS changes within the proscribed TTL. Such
> aggressive caching will lead to service disruptions on your client as
> Twitter shifts load between IP addresses.
> "
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.

[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010

[DustyReagan]

I 2nd Dewald's sentiments.

On Dec 27, 8:29 pm, Dewald Pretorius  wrote:
> What is being deprecated here is the old pagination method with the
> &page parameter.
>
> As noted earlier, it is going to cause great pain if the API is going
> to assume a cursor of -1 if no cursor is specified, and hence enforce
> the use of cursors regardless of the size of the social graph.
>
> The API is currently comfortably returning social graphs smaller than
> 200,000 members in one call. I very rarely get a 502 on social graphs
> of that size. It makes no sense to force us to make 40 API where 1 API
> call currently suffices and works. Those 40 API calls take between 40
> and 80 seconds to complete, as opposed to 1 to 2 seconds for the
> single API call. Multiply that by a few thousand Twitter accounts, and
> it adds hours of additional processing time, which is completely
> unnecessary, and will make getting through a large number of accounts
> virtually impossible.
>
> On Dec 27, 7:45 pm, Zac Bowling  wrote:
>
>
>
> > I agree with the others to some extent. Although its a good signal to stop
> > using something ASAP when something is depreciated, saying depreciated and
> > not giving definite time-line on it's removal isn't good either. (Source
> > params are deprecated but still work and don't have solid deprecation date,
> > and I'm still going on using them because OAuth sucks for desktop/mobile
> > situations still and would die with a 15 day heads up on removal).
>
> > Also iPhone app devs using this API will would probably have a hard time
> > squeezing a 15 day return on Apple right now.
>
> > Zac Bowling
>
> > On Sun, Dec 27, 2009 at 3:28 PM, Dewald Pretorius  wrote:
> > > I agree 100%.
>
> > > Calls without the starting cursor of -1 must still return all
> > > followers as is currently the case.
>
> > > As a test I've set my system to use cursors on all calls. It inflates
> > > the processing time so much that things become completely unworkable.
>
> > > We can programmatically use cursors if showuser says that the person
> > > has more than a certain number of friends/followers. That's what I'm
> > > currently doing, and it works beautifully. So, please do not force us
> > > to use cursors on all calls.
>
> > > On Dec 24, 7:20 am, Aki  wrote:
> > > > I agree with PJB. The previous announcements only said that the
> > > > pagination will be deprecated.
>
> > > > 1.http://groups.google.com/group/twitter-api-announce/browse_thread/thr.
> > > ..
> > > > 2.http://groups.google.com/group/twitter-api-announce/browse_thread/thr.
> > > ..
>
> > > > However, both of the announcements did not say that the API call
> > > > "without" page parameter to get
> > > > all IDs will be removed or replaced with cursor pagination.
> > > > The deprecation of this method is not being documented as PJB said.
>
> > > > On Dec 24, 5:00 pm, PJB  wrote:
>
> > > > > Why hasn't this been announced before?  Why does the API suggest
> > > > > something totally different?  At the very least, can you please hold
> > > > > off on deprecation of this until 2/11/2010?  This is a new API change.
>
> > > > > On Dec 23, 7:45 pm, Raffi Krikorian  wrote:
>
> > > > > > yes - if you do not pass in cursors, then the API will behave as
> > > though you
> > > > > > requested the first cursor.
>
> > > > > > > Willhelm:
>
> > > > > > > Your announcement is apparently expanding the changeover from page
> > > to
> > > > > > > cursor in new, unannounced ways??
>
> > > > > > > The API documentation page says: "If the cursor parameter is not
> > > > > > > provided, all IDs are attempted to be returned, but large sets of
> > > IDs
> > > > > > > will likely fail with timeout errors."
>
> > > > > > > Yesterday you wrote: "Starting soon, if you fail to pass a cursor,
> > > the
> > > > > > > data returned will be that of the first cursor (-1) and the
> > > > > > > next_cursor and previous_cursor elements will be included."
>
> > > > > > > I can understand the need to swap from page to cursor, but was
> > > pleased
> > > > > > > that a single call was still available to return (or attempt to
> > > > > > > return) all friend/follower ids.  Now you are saying that, in
> > > addition
> > > > > > > to the changeover from page to cursor, you are also getting rid of
> > > > > > > this?
>
> > > > > > > Can you please confirm/deny?
>
> > > > > > > On Dec 22, 4:13 pm, Wilhelm Bierbaum  wrote:
> > > > > > > > We noticed that some clients are still calling social graph
> > > methods
> > > > > > > > without cursor parameters. We wanted to take time to make sure
> > > that
> > > > > > > > people were calling the updated methods which return data with
> > > cursors
> > > > > > > > instead of the old formats that do not.
>
> > > > > > > > As previously announced in September (http://bit.ly/46x1iL) and
> > > > > > > > November (http://bit.ly/3UQ0LU), the legacy data formats
> > > returned
> > > > > > > > as a result of calling social graph endpoints without a cursor
> > > > > > > > pa

[twitter-dev] Re: Platform announcements from LeWeb

[funkatron]

Will this be posted to the dev announcement list as well? I missed
this until now because it was not -- only caught it by chance in my
friends timeline via ReadWriteWeb.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On Dec 28, 12:24 am, Ryan Sarver  wrote:
> Hey all,
>
> Now that the dust has settled a bit and we are in the midst of the holidays
> I wanted to email everyone and provide some more details on the
> announcements we made a few weeks ago at LeWeb.
>
> *50,000 apps*
> We are continually amazed by all the incredible work the ecosystem does as a
> whole and we proud that developers have created over 50,000 applications
> that allow people to experience Twitter in so many different ways. We are
> really looking forward to what 2010 has in store as we put more emphasis on
> supporting the ecosystem better and maturing as a platform. We are humbled
> by and appreciative all the hard work you do. Please continue to give us
> feedback -- both good and bad -- on how we can support you better in your
> efforts to build awesome apps.
>
> *Auth announcements*
> With the recent launches of Retweet, Lists and Geotagging we have seen
> applications struggle to provide the experience they want for their users
> within the 150 req/hr limit. We are excited to open the skies up a bit and
> provide some more room for developers to work within. Starting in a few
> weeks all OAuth requests to api.twitter.com/1/ will be able to take
> advantage of a 10x rate limit increase. Basic Whitelisting still exists and
> is unchanged. We look forward to what this means in terms of the increased
> richness around the user experience in Twitter apps.
>
> *Developer Site*
> From the beginning we have used a disparate set of tools to help support the
> community -- from the apiwiki, to code.google.com for issues to this mailing
> group. It was a great way to get started quickly with fairly robust tools,
> but we need a place for developers to start from and help them find the
> right answers to their questions and help them solve their problems. We have
> announced a new Developer Site that begins to consolidate these
> communications channels and tools into a single place while adding some new,
> exciting tools to help developers. There will be new reference
> documentation, search, API console, API status dashboard (external
> monitoring service) and clearer documentation of policies. We are investing
> heavily in this area and will continue to improve the tools and content for
> the ecosystem to make sure that you have everything you need to get started
> and for continued support. We are really interested in getting your feedback
> on what will create a great site, so please let us know your wishlist of
> things that will help you be a more informed and more efficient developer.
>
> *Chirp - Twitter Developer Conference*
> Personally one of the most exciting announcements is that we will be
> throwing the first official Twitter Developer Conference which we are
> calling Chirp. It will be a two day event focused on equipping developers
> with all the tools they need to go forth and build great things. Day One
> will be filled with speakers from Twitter and the ecosystem talking about a
> broad range of topics like our roadmap, the Streaming API, how to develop
> desktop applications, sentiment analysis, user research and more. At the end
> of Day One we will kick off a 24-hour hack event with lots of great
> announcements and surprises already lined up. We'll also be filling Day Two
> with some workshops on specific topics for developers who want to dive deep
> in certain areas. There are lots of great surprises in store for the event
> and we hope to see lots of you there.
>
> *Firehose for everyone*
> Finally, the announcement that has garnered the most coverage and
> excitement. As I stated in the session at LeWeb we are committed to
> providing a framework for any company big or small, rich or poor to do a
> deal with us to get access to the Firehose in the same way we did deals with
> Google and Microsoft. We want everyone to have the opportunity -- terms will
> vary based on a number of variables but we want a two-person startup in a
> garage to have the same opportunity to build great things with the full feed
> that someone with a billion dollar market cap does. There are still a lot of
> details to be fleshed out and communicated, but this a top priority for us
> and we look forward to what types of companies and products get built on top
> of this unique and rich stream.
>
> Sorry for the long-winded email, but there is lots of really exciting stuff
> for us to be talking about. As always, we are very interested in getting
> your feedback on the announcements and more generally on how we can continue
> to improve how we work together. As I said a few times in the session, our
> success is dependent on your success so please let us know what we can do to

Re: [twitter-dev] oAuth new stuff?

[Isaiah]

i understand that you have to tow the line. i agree with it — at least in 
principle. i like oauth. i understand it. i *want* to put it in my app. aside 
from my desktop client, i released an open source oAuth solution: 
http://thurly.net//5nl

yet, of the prominent mac clients (tweetie, twitteriffic, socialite, beak, 
bluebird, kiwi) only one is currently using oAuth. the reasons are painfully 
obvious and have been discussed here and elsewhere ad nauseum:
http://groups.google.com/group/twitter-development-talk/search?hl=en&group=twitter-development-talk&q=oauth+desktop&qt_g=Search+this+group

i suspect that other desktop app devs feel like i do: that the announced oauth 
addendum was a sea change that looked like a realistic way forward. i was ready 
to hi-five the first person i saw when i read about it:
http://groups.google.com/group/twitter-development-talk/msg/18b38db599f6ad98?hl=en

i'm not asking for anything new or different from what has already been 
announced. i was just hoping for a bit more detail, that's all.

isaiah

On Dec 29, 2009, at 3:19 PM, Raffi Krikorian wrote:

> if your application has access to a web browser, then i would strongly 
> suggest that you implement a workflow where your user goes to a twitter.com 
> page -- this workflow is intended to protect the usernames and passwords of 
> Twitter users because they can trust that an unknown app does not have access 
> to their passwords.
> 
> On Tue, Dec 29, 2009 at 2:31 PM, Isaiah Carew  wrote:
> 
> bummer.
> 
> i don't mean to be rude, but it sure feels like there is a large gap between 
> the PR announcement a couple weeks ago and the reality on the ground.  i'm 
> trying to be patient in letting the info trickle down.  i guess i'll ask 
> again in a couple weeks?
> 
> 
> 
> 
> 
> until then, my app is limping along with basic auth without attribution.
> 
> isaiah
> 
> On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote:
> 
>> i don't know.  sorry that i forgot to address your question.
>> 
>> On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew  wrote:
>> 
>> and how 'bout that off topic question?
>> 
>> a non-silent-treatment sort of answer would be really great -- even if it's 
>> "i can't tell you" or "i don't know" or "that's on a need to know basis and 
>> you don't need to know." or "you want the truth, you can't handle the 
>> truth!" or whatever.
>> 
>> my biggest concern is that it won't come before the deprecation of oAuth -- 
>> and I'll have to implement a pin bases solution in the interim, then rip 
>> that out, then implement the new flow if/when it's finally included in the 
>> twitter api.  if that's the case, then i'm going to need to budget some more 
>> $$ for this effort.
>> 
>> i'm just looking at what sort of effort and money i'm going to have to spend 
>> on this in the next six months.
>> 
>> thanks,
>> isaiah
>> 
>> 
>> On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote:
>> 
>>> Also, off topic:
>>> Any news on when we can expect the new oAuth with username/password flow to 
>>> make its way into the API?  If you can't let me know, or you don't know, I 
>>> understand, but it would be good to hear whatever the case. 
>>> 
>>> Thanks,
>>> Isaiah
>> 
>> 
>> 
>> 
>> -- 
>> Raffi Krikorian
>> Twitter Platform Team
>> http://twitter.com/raffi
> 
> 
> 
> 
> -- 
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi

RE: [twitter-dev] FW: de-latinisation of the web - http://blog.collins.net.pr/2009/12/de-latinisation-of-web.html

[Dean Collins]

Lol you mean apart from how this url below looks like twitter.com, smells like 
twitter.com ...But aint Twitter.com :-)

 

>  http://twittеr.com     <

 

 

I don't know about you Abraham as you are far more experienced than I am, but 
if I run a web based application that relied heavily on urls and people would 
love to hack/phish for any number of reasons this would be something worth 
talking about (eg my developers today have implemented a series counter 
measures against non-latin text).

 

But hey what do I know. I cant even code.

 

 

Cheers,

Dean

 



From: twitter-development-talk@googlegroups.com 
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Abraham Williams
Sent: Tuesday, December 29, 2009 7:38 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] FW: de-latinisation of the web - 
http://blog.collins.net.pr/2009/12/de-latinisation-of-web.html

 

What does this have to do with the Twitter API other then the general 
connection to the internet?

On Mon, Dec 28, 2009 at 23:53, Dean Collins  wrote:

UPDATE - This is really really bad - check out the paypal phishing example on 
my blog already using Cyrillic characters


http://blog.collins.net.pr/2009/12/de-latinisation-of-web.html

 



Please forward to everyone in a position to stop ICANN, i cant believe they 
didn't think of this in advance.

 

 

 

Regards,

Dean Collins
Cognation Inc
d...@cognation.net
 +1-212-203-4357   New York
+61-2-9016-5642   (Sydney in-dial).
+44-20-3129-6001 (London in-dial).

 




-- 
Abraham Williams | Blog | http://the.hackerconundrum.com
Project | Intersect | http://intersect.labs.poseurtech.com
Hacker | http://abrah.am | http://twitter.com/abraham
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Madison, WI, United States 

Re: [twitter-dev] FW: de-latinisation of the web - http://blog.collins.net.pr/2009/12/de-latinisation-of-web.html

[Abraham Williams]

What does this have to do with the Twitter API other then the general
connection to the internet?

On Mon, Dec 28, 2009 at 23:53, Dean Collins  wrote:

>   UPDATE - This is really really bad - check out the paypal phishing
> example on my blog already using Cyrillic characters
>
>
> http://blog.collins.net.pr/2009/12/de-latinisation-of-web.html
>
>
>
>
>
> Please forward to everyone in a position to stop ICANN, i cant believe they
> didn't think of this in advance.
>
>
>
>
>
>
>
> Regards,
>
> Dean Collins
> Cognation Inc
> d...@cognation.net
> +1-212-203-4357   New York
> +61-2-9016-5642   (Sydney in-dial).
> +44-20-3129-6001 (London in-dial).
>
>
>



-- 
Abraham Williams | Blog | http://the.hackerconundrum.com
Project | Intersect | http://intersect.labs.poseurtech.com
Hacker | http://abrah.am | http://twitter.com/abraham
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Madison, WI, United States

Re: [twitter-dev] Re: "Failed to validate oauth signature and token" error

[Raffi Krikorian]

>
> > not right now.
>
> hmm, if it is so then how does the "python-twitter" (http://
> code.google.com/p/python-twitter/) work? it allows posting messages
> and much more without the browser. maybe i missed smth...
> thank you for clarifications.
>

python twitter, i assume, is using basic authentication for its interactions
with the Twitter API.  this, however, has the disadvantages -
http://apiwiki.twitter.com/OAuth+Example+-+Ruby (see the "what does oauth
give me").

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] oAuth new stuff?

[Raffi Krikorian]

if your application has access to a web browser, then i would strongly
suggest that you implement a workflow where your user goes to a
twitter.compage -- this workflow is intended to protect the usernames
and passwords of
Twitter users because they can trust that an unknown app does not have
access to their passwords.

On Tue, Dec 29, 2009 at 2:31 PM, Isaiah Carew  wrote:

>
> bummer.
>
> i don't mean to be rude, but it sure feels like there is a large gap
> between the PR announcement a couple weeks ago and the reality on the
> ground.  i'm trying to be patient in letting the info trickle down.  i guess
> i'll ask again in a couple weeks?
>
> 
> 
> 
>
> until then, my app is limping along with basic auth without attribution.
>
> isaiah
>
> On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote:
>
> i don't know.  sorry that i forgot to address your question.
>
> On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew  wrote:
>
>>
>> and how 'bout that off topic question?
>>
>> a non-silent-treatment sort of answer would be really great -- even if
>> it's "i can't tell you" or "i don't know" or "that's on a need to know basis
>> and you don't need to know." or "you want the truth, you can't handle the
>> truth!" or whatever.
>>
>> my biggest concern is that it won't come before the deprecation of oAuth
>> -- and I'll have to implement a pin bases solution in the interim, then rip
>> that out, then implement the new flow if/when it's finally included in the
>> twitter api.  if that's the case, then i'm going to need to budget some more
>> $$ for this effort.
>>
>> i'm just looking at what sort of effort and money i'm going to have to
>> spend on this in the next six months.
>>
>> thanks,
>> isaiah
>>
>>
>> On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote:
>>
>> Also, off topic:
>>> Any news on when we can expect the new oAuth with username/password flow
>>> to make its way into the API?  If you can't let me know, or you don't know,
>>> I understand, but it would be good to hear whatever the case.
>>>
>>> Thanks,
>>> Isaiah
>>>
>>
>>
>
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
>
>


-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: "Failed to validate oauth signature and token" error

[varnie]

On Dec 30, 2:07 am, Raffi Krikorian  wrote:
> not right now.

hmm, if it is so then how does the "python-twitter" (http://
code.google.com/p/python-twitter/) work? it allows posting messages
and much more without the browser. maybe i missed smth...
thank you for clarifications.

Re: [twitter-dev] oAuth new stuff?

[Isaiah Carew]

bummer.

i don't mean to be rude, but it sure feels like there is a large gap  
between the PR announcement a couple weeks ago and the reality on the  
ground.  i'm trying to be patient in letting the info trickle down.  i  
guess i'll ask again in a couple weeks?






until then, my app is limping along with basic auth without attribution.

isaiah

On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote:


i don't know.  sorry that i forgot to address your question.

On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew  wrote:

and how 'bout that off topic question?

a non-silent-treatment sort of answer would be really great -- even  
if it's "i can't tell you" or "i don't know" or "that's on a need to  
know basis and you don't need to know." or "you want the truth, you  
can't handle the truth!" or whatever.


my biggest concern is that it won't come before the deprecation of  
oAuth -- and I'll have to implement a pin bases solution in the  
interim, then rip that out, then implement the new flow if/when it's  
finally included in the twitter api.  if that's the case, then i'm  
going to need to budget some more $$ for this effort.


i'm just looking at what sort of effort and money i'm going to have  
to spend on this in the next six months.


thanks,
isaiah


On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote:


Also, off topic:
Any news on when we can expect the new oAuth with username/password  
flow to make its way into the API?  If you can't let me know, or  
you don't know, I understand, but it would be good to hear whatever  
the case.


Thanks,
Isaiah





--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010

[chinaski007]

Why is Twitter announcing a major API change over the holidays?  Why
are they giving us just a few (mostly holiday!) days to account for
it?

Please either a) preserve the existing calls, or b) give us a 3 month
window before deprecating.  This is a new API change.

Given that many have commented on this, there is clearly value in
preserving this call.  It is beyond me as to why Twitter feels it is
necessary to limit what is clearly valuable.

On Dec 22, 4:13 pm, Wilhelm Bierbaum  wrote:
> We noticed that some clients are still calling social graph methods
> without cursor parameters. We wanted to take time to make sure that
> people were calling the updated methods which return data with cursors
> instead of the old formats that do not.
>
> As previously announced in September (http://bit.ly/46x1iL) and
> November (http://bit.ly/3UQ0LU), the legacy data formats returned
> as a result of calling social graph endpoints without a cursor
> parameter are deprecated and will be removed.
>
> These formats have been removed from the API wiki since September.
>
> You should always pass a cursor parameter. Starting soon, if you fail
> to pass a cursor, the data returned will be that of the first cursor
> (-1) and the next_cursor and previous_cursor elements will be included.
>
> If you aren't seeing next_cursor and previous_cursor in your results,
> you are getting data back in the old format. You will need to adjust
> your parser to handle the new format.
>
> We're going to start assuming you want data in the new format
> (users_list / users / user or id_list / ids / id) instead of the old
> format (users / user or ids / id) regardless of your passing a cursor
> parameter as of 1/11/2010.
>
> * The old formats will no longer be returned after 1/11/2010.
> * Start using the new formats now by passing the 'cursor' parameter.
>
> To recap, the old endpoints at
>
>    /statuses/friends.xml
>    /statuses/followers.xml
>
> returned
>
>     
>       
>       
>       
>     
>
> or JSON like [{/*user record*/ /*, .../]
>
> whereas
>
>         /statuses/friends.xml?cursor=n
>         /statuses/followers.xml?cursor=n
>
> return data that looks like
>
>     
>       
>           
>           
>           
>       
>       7128872798413429387
>       0
>     
>
> or, the JSON equivalent:
>
>     {"users":[{/*user record*/} /*, ...*/], "next_cursor":0,
> "previous_cursor":0}
>
> and the old endpoints at
>
>     /friends/ids.xml
>     /followers/ids.xml
>
> returned data that looks like
>
>     
>       1
>       2
>       3
>     
>
> whereas
>
>     /friends/ids.xml?cursor=n
>     /followers/ids.xml?cursor=n
>
> return data that looks like
>
>     
>       
>         1
>         2
>         3
>       
>       1288724293877798413
>       -1300794057949944903
>     
>
> or, the JSON equivalent:
>
>     {"ids":[1, 2, 3], "next_cursor":0, "previous_cursor":0}
>
> If you have any questions or comments, please feel free to post them
> to twitter-development-talk.
>
> Thanks!
>
> --
> Wilhelm Bierbaum
> Twitter Platform Team

Re: [twitter-dev] Re: oAuth Authenticate vs. Authorize (force_login)

[Abraham Williams]

@andy: oauth/authenticate is not signed other then with SSL. You are just
passing the request token to Twitter.

@aaron: authenticate and authorize both result in access tokens that allow
you to act on behalf of the user. The first time a user goes through
authenticate they authorize the application.


On Tue, Dec 29, 2009 at 14:16, Aaron Rankin  wrote:

> Does authenticate actually "authorize" the app to perform operations
> on behalf of the user? My understanding is the user must first
> "authorize" the app and then the app can send them through
> "authenticate" in the future as a login check. If the user never
> approves the app in an "authorize" operation, I don't think the app
> has the right to perform and twitter operations on behalf of the user.
>
> On Dec 29, 1:44 pm, Andy Freeman  wrote:
> > > Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> > > args} this stuff is working very well for me;) Thank you for your
> > > hint.
> >
> > While that "works", I think that it shouldn't.
> >
> > (1) I don't think that it's a legal url because it has two '?'s.
> > (2) force_login=true isn't part of the signed arguments so it should
> > be rejected.  (The whole point of signing is to block man-in-the-
> > middle attacks that alter arguments.)
> >
> > I haven't tried including force_login=true in the signed arguments.
> > Are you saying that it doesn't work?  If so, I'd say that that's a
> > bug, as is the above.
> >
> > Thanks,
> > -andy
> >
> > On Dec 28, 9:41 pm, el moro  wrote:
> >
> > > Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> > > args} this stuff is working very well for me;) Thank you for your
> > > hint.
> >
> > > Axel
> >
> > > On 29 Dez., 03:21, Andy Freeman  wrote:
> >
> > > > > The difference (to my understanding) is that Authenticate does not
> > > > > authorize the app.
> >
> > > > Huh?
> >
> > > > Whether I use authorize or authenticate, my app can tweet etc on the
> > > > user's behalf.
> >
> > > > What, exactly, do you think that authenticate and authorize do?  I
> > > > think that both can give my application a token that I can use to
> take
> > > > actions on the user's behalf.  I think that both do some sort of
> login
> > > > or check before doing so.
> >
> > > > The difference that I see is in how twitter presents its questions
> > > > regarding the account that is allowing my application to do its
> thing.
> >
> > > > That, and the bit that authenticate leaves folks logged in to
> twitter.
> >
> > > > On Dec 28, 5:27 pm, Justyn  wrote:
> >
> > > > > The difference (to my understanding) is that Authenticate does not
> > > > > authorize the app. We need to have the app authorized but want to
> give
> > > > > the user the chance to choose which account to login with (and
> > > > > Authorize).
> >
> > > > > Ideally, twitter state would not be effected, and user could
> authorize
> > > > > an app with desired account (regardless of session) without
> clicking
> > > > > "sign out".
> >
> > > > > Justyn
> >
> > > > > On Dec 28, 5:36 pm, Abraham Williams <4bra...@gmail.com> wrote:
> >
> > > > > > That is true. Authenticate currently leaves the user logged in.
> >
> > > > > > I would prefer that get fixed rather then adding force_login to
> authorize as
> > > > > > I view leaving users logged in as a security risk. Apparently
> Twitter does
> > > > > > not:
> >
> > > > > >http://code.google.com/p/twitter-api/issues/detail?id=1070
> >
> > > > > > On Mon, Dec 28, 2009 at 17:13, Andy Freeman <
> ana...@earthlink.net> wrote:
> > > > > > > > Then use authenticate. It accomplishes the same effect of
> authorize.
> >
> > > > > > > Does it?  My notes say that authenticate leaves the user logged
> into
> > > > > > > twitter if they weren't before and that authorize doesn't.
> >
> > > > > > > For my purposes, I'd like to force the user to specify their
> twitter
> > > > > > > account and password even if they're already logged in and not
> change
> > > > > > > their login state (as far as twitter is concerned) at all.
> >
> > > > > > > I can imagine folks who'd like to allow users to quickly
> authorize the
> > > > > > > use of the logged in account (if any)
> >
> > > > > > > I can't imagine anyone who'd want to change the user's logged
> in
> > > > > > > state.
> >
> > > > > > > On Dec 27, 6:08 pm, Abraham Williams <4bra...@gmail.com>
> wrote:
> > > > > > > > Then use authenticate. It accomplishes the same effect of
> authorize.
> >
> > > > > > > > On Sun, Dec 27, 2009 at 17:42, Justyn <
> justyn.how...@gmail.com> wrote:
> > > > > > > > > Thanks Abraham - I understand this is the current
> limitation, however
> > > > > > > > > I think there is a need for the foce_login to be available
> with the
> > > > > > > > > authorize function. The authorize landing page is confusing
> to users
> > > > > > > > > who want to sign-in with an account that is different from
> their
> > > > > > > > > latest session. The "sign-out" option is not obvious to
> users. Thi

Re: [twitter-dev] oAuth new stuff?

[Raffi Krikorian]

i don't know.  sorry that i forgot to address your question.

On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew  wrote:

>
> and how 'bout that off topic question?
>
> a non-silent-treatment sort of answer would be really great -- even if it's
> "i can't tell you" or "i don't know" or "that's on a need to know basis and
> you don't need to know." or "you want the truth, you can't handle the
> truth!" or whatever.
>
> my biggest concern is that it won't come before the deprecation of oAuth --
> and I'll have to implement a pin bases solution in the interim, then rip
> that out, then implement the new flow if/when it's finally included in the
> twitter api.  if that's the case, then i'm going to need to budget some more
> $$ for this effort.
>
> i'm just looking at what sort of effort and money i'm going to have to
> spend on this in the next six months.
>
> thanks,
> isaiah
>
>
> On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote:
>
> Also, off topic:
>> Any news on when we can expect the new oAuth with username/password flow
>> to make its way into the API?  If you can't let me know, or you don't know,
>> I understand, but it would be good to hear whatever the case.
>>
>> Thanks,
>> Isaiah
>>
>
>


-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] oAuth new stuff?

[Isaiah Carew]

and how 'bout that off topic question?

a non-silent-treatment sort of answer would be really great -- even if  
it's "i can't tell you" or "i don't know" or "that's on a need to know  
basis and you don't need to know." or "you want the truth, you can't  
handle the truth!" or whatever.


my biggest concern is that it won't come before the deprecation of  
oAuth -- and I'll have to implement a pin bases solution in the  
interim, then rip that out, then implement the new flow if/when it's  
finally included in the twitter api.  if that's the case, then i'm  
going to need to budget some more $$ for this effort.


i'm just looking at what sort of effort and money i'm going to have to  
spend on this in the next six months.


thanks,
isaiah


On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote:


Also, off topic:
Any news on when we can expect the new oAuth with username/password  
flow to make its way into the API?  If you can't let me know, or you  
don't know, I understand, but it would be good to hear whatever the  
case.


Thanks,
Isaiah

Re: [twitter-dev] Twitter Truncation

[Raffi Krikorian]

hi - its (fortunately/unfortunately) been like that for a few months.  its
high on my list to throw an error when that occurs, and i'm sorry it hasn't
been done yet.

On Tue, Dec 29, 2009 at 12:19 PM, akademicjeanius
wrote:

> Just wondering, when did Twitter decide to stop truncating API tweets
> over 140 characters and just toss them out completely? This has bitten
> me in the a**.
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] Re: "Failed to validate oauth signature and token" error

[Raffi Krikorian]

not right now.

i have to emphasize, the reason the browser is "a good thing" is that the
user can see that he is not giving his twitter password to your application.

On Tue, Dec 29, 2009 at 10:46 AM, varnie  wrote:

> Good day. I've solved my issue. One more question - are there any ways
> to get authorization without having to use the browser? if you're
> awared of any solutions please let me know, thanks.
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] Ambiguity with 401 error response code

[Raffi Krikorian]

uhh.  i can't guarantee this is an exhaustive list, but off the top of
my head i think those are the two that developers will normally see in the
401.

On Tue, Dec 29, 2009 at 12:36 PM, Isaiah Carew  wrote:

>
> Are there other error conditions that are similarly ganged up into 401?  Or
> are these two the complete list?
> Are there other codes that have similarly ganged up error conditions that
> can only be distinguished by the response text?
>
> Are the expected responses (not just the codes) for different conditions
> documented somewhere?
>
> Also, off topic:
> Any news on when we can expect the new oAuth with username/password flow to
> make its way into the API?  If you can't let me know, or you don't know, I
> understand, but it would be good to hear whatever the case.
>
> Thanks,
> Isaiah
>
> On Dec 29, 2009, at 9:45 AM, Raffi Krikorian wrote:
>
> hi eric.
>
> yup - you've hit it right on the head.  one of the main initiatives in us
> starting to version our API is so that we can really consolidate and make
> our error codes consistent.  unfortunately, for legacy compatibility
> reasons, we can't change the second case to have a 402 error and we will
> have to keep it as a 401.
>
> what you could do is parse the response that comes back in the 401,
> however.  in the case that your password is wrong, the error should be
>
> "Could not authenticate you."
>
> for basic auth and OAuth. the second case has an error of
>
> "Not authorized"
>
> On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip <
> e...@marcoullier.com> wrote:
>
>> We're trying to build some logic into our data collector and we've
>> been fighting with an issue for a while involving the 401
>> "Unauthorized" error code.
>>
>> There are two instances where I can get this response
>>
>> 1) Bad credentials.  I try to log in with an invalid username or
>> password.
>> 2) I don't have access to a specific user's private account.
>>
>> The former can be a real problem for a user.  I changed my password a
>> few weeks ago and forgot that I was using it for whitelisted REST API
>> access.  Querying three times in rapid succession with a bad password
>> causes a temporary lockdown of a user's account.  I was querying once
>> per second and locked the account for a five days.  This is an account-
>> level issue and the proper way to deal with this from our perspective
>> is to immediately sleep the poller for 30 minutes and send an alert
>> about bad credentials.
>>
>> This is completely different than if someone I'm following has taken
>> their account private.  In this case, sleeping for 30 minutes (or any
>> amount of time, really) is overkill.  Unless I'm querying for a single
>> person over and over, there's no reason to pause before moving onto
>> the next rule that I'm querying for.
>>
>> Unfortunately, we have no way to disambiguate between the two 401s and
>> we're forced to either lock someone's account (ignoring 401s) or
>> severely reduce their polling efficiency (acting on 401s).
>>
>> Best case would be to break these two error conditions out into
>> separate error codes.  Perhaps a 401 for bad credentials and a 402 for
>> lack of authorization for a specific piece of content.
>>
>> Please let know if I've overlooked something that would help me
>> disambiguate the use cases in the current system.
>>
>> Thanks!
>> Eric
>>
>>
>>
>
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
>
>


-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: Ambiguity with 401 error response code

[Eric Marcoullier @ Gnip]

Heya, this will definitely work for now.  Thanks for the good idea.

Eric

On Dec 29, 10:45 am, Raffi Krikorian  wrote:
> hi eric.
>
> yup - you've hit it right on the head.  one of the main initiatives in us
> starting to version our API is so that we can really consolidate and make
> our error codes consistent.  unfortunately, for legacy compatibility
> reasons, we can't change the second case to have a 402 error and we will
> have to keep it as a 401.
>
> what you could do is parse the response that comes back in the 401, however.
>  in the case that your password is wrong, the error should be
>
> "Could not authenticate you."
>
> for basic auth and OAuth. the second case has an error of
>
> "Not authorized"
>
> On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip <
>
>
>
> e...@marcoullier.com> wrote:
> > We're trying to build some logic into our data collector and we've
> > been fighting with an issue for a while involving the 401
> > "Unauthorized" error code.
>
> > There are two instances where I can get this response
>
> > 1) Bad credentials.  I try to log in with an invalid username or
> > password.
> > 2) I don't have access to a specific user's private account.
>
> > The former can be a real problem for a user.  I changed my password a
> > few weeks ago and forgot that I was using it for whitelisted REST API
> > access.  Querying three times in rapid succession with a bad password
> > causes a temporary lockdown of a user's account.  I was querying once
> > per second and locked the account for a five days.  This is an account-
> > level issue and the proper way to deal with this from our perspective
> > is to immediately sleep the poller for 30 minutes and send an alert
> > about bad credentials.
>
> > This is completely different than if someone I'm following has taken
> > their account private.  In this case, sleeping for 30 minutes (or any
> > amount of time, really) is overkill.  Unless I'm querying for a single
> > person over and over, there's no reason to pause before moving onto
> > the next rule that I'm querying for.
>
> > Unfortunately, we have no way to disambiguate between the two 401s and
> > we're forced to either lock someone's account (ignoring 401s) or
> > severely reduce their polling efficiency (acting on 401s).
>
> > Best case would be to break these two error conditions out into
> > separate error codes.  Perhaps a 401 for bad credentials and a 402 for
> > lack of authorization for a specific piece of content.
>
> > Please let know if I've overlooked something that would help me
> > disambiguate the use cases in the current system.
>
> > Thanks!
> > Eric
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi

[twitter-dev] Re: "Failed to validate oauth signature and token" error

[varnie]

Good day. I've solved my issue. One more question - are there any ways
to get authorization without having to use the browser? if you're
awared of any solutions please let me know, thanks.

[twitter-dev] Twitter Truncation

[akademicjeanius]

Just wondering, when did Twitter decide to stop truncating API tweets
over 140 characters and just toss them out completely? This has bitten
me in the a**.

Re: [twitter-dev] Ambiguity with 401 error response code

[Isaiah Carew]

Are there other error conditions that are similarly ganged up into  
401?  Or are these two the complete list?
Are there other codes that have similarly ganged up error conditions  
that can only be distinguished by the response text?


Are the expected responses (not just the codes) for different  
conditions documented somewhere?


Also, off topic:
Any news on when we can expect the new oAuth with username/password  
flow to make its way into the API?  If you can't let me know, or you  
don't know, I understand, but it would be good to hear whatever the  
case.


Thanks,
Isaiah

On Dec 29, 2009, at 9:45 AM, Raffi Krikorian wrote:


hi eric.

yup - you've hit it right on the head.  one of the main initiatives  
in us starting to version our API is so that we can really  
consolidate and make our error codes consistent.  unfortunately, for  
legacy compatibility reasons, we can't change the second case to  
have a 402 error and we will have to keep it as a 401.


what you could do is parse the response that comes back in the 401,  
however.  in the case that your password is wrong, the error should be


"Could not authenticate you."

for basic auth and OAuth. the second case has an error of

"Not authorized"

On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip > wrote:

We're trying to build some logic into our data collector and we've
been fighting with an issue for a while involving the 401
"Unauthorized" error code.

There are two instances where I can get this response

1) Bad credentials.  I try to log in with an invalid username or
password.
2) I don't have access to a specific user's private account.

The former can be a real problem for a user.  I changed my password a
few weeks ago and forgot that I was using it for whitelisted REST API
access.  Querying three times in rapid succession with a bad password
causes a temporary lockdown of a user's account.  I was querying once
per second and locked the account for a five days.  This is an  
account-

level issue and the proper way to deal with this from our perspective
is to immediately sleep the poller for 30 minutes and send an alert
about bad credentials.

This is completely different than if someone I'm following has taken
their account private.  In this case, sleeping for 30 minutes (or any
amount of time, really) is overkill.  Unless I'm querying for a single
person over and over, there's no reason to pause before moving onto
the next rule that I'm querying for.

Unfortunately, we have no way to disambiguate between the two 401s and
we're forced to either lock someone's account (ignoring 401s) or
severely reduce their polling efficiency (acting on 401s).

Best case would be to break these two error conditions out into
separate error codes.  Perhaps a 401 for bad credentials and a 402 for
lack of authorization for a specific piece of content.

Please let know if I've overlooked something that would help me
disambiguate the use cases in the current system.

Thanks!
Eric





--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: oAuth Authenticate vs. Authorize (force_login)

[Aaron Rankin]

Does authenticate actually "authorize" the app to perform operations
on behalf of the user? My understanding is the user must first
"authorize" the app and then the app can send them through
"authenticate" in the future as a login check. If the user never
approves the app in an "authorize" operation, I don't think the app
has the right to perform and twitter operations on behalf of the user.

On Dec 29, 1:44 pm, Andy Freeman  wrote:
> > Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> > args} this stuff is working very well for me;) Thank you for your
> > hint.
>
> While that "works", I think that it shouldn't.
>
> (1) I don't think that it's a legal url because it has two '?'s.
> (2) force_login=true isn't part of the signed arguments so it should
> be rejected.  (The whole point of signing is to block man-in-the-
> middle attacks that alter arguments.)
>
> I haven't tried including force_login=true in the signed arguments.
> Are you saying that it doesn't work?  If so, I'd say that that's a
> bug, as is the above.
>
> Thanks,
> -andy
>
> On Dec 28, 9:41 pm, el moro  wrote:
>
> > Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> > args} this stuff is working very well for me;) Thank you for your
> > hint.
>
> > Axel
>
> > On 29 Dez., 03:21, Andy Freeman  wrote:
>
> > > > The difference (to my understanding) is that Authenticate does not
> > > > authorize the app.
>
> > > Huh?
>
> > > Whether I use authorize or authenticate, my app can tweet etc on the
> > > user's behalf.
>
> > > What, exactly, do you think that authenticate and authorize do?  I
> > > think that both can give my application a token that I can use to take
> > > actions on the user's behalf.  I think that both do some sort of login
> > > or check before doing so.
>
> > > The difference that I see is in how twitter presents its questions
> > > regarding the account that is allowing my application to do its thing.
>
> > > That, and the bit that authenticate leaves folks logged in to twitter.
>
> > > On Dec 28, 5:27 pm, Justyn  wrote:
>
> > > > The difference (to my understanding) is that Authenticate does not
> > > > authorize the app. We need to have the app authorized but want to give
> > > > the user the chance to choose which account to login with (and
> > > > Authorize).
>
> > > > Ideally, twitter state would not be effected, and user could authorize
> > > > an app with desired account (regardless of session) without clicking
> > > > "sign out".
>
> > > > Justyn
>
> > > > On Dec 28, 5:36 pm, Abraham Williams <4bra...@gmail.com> wrote:
>
> > > > > That is true. Authenticate currently leaves the user logged in.
>
> > > > > I would prefer that get fixed rather then adding force_login to 
> > > > > authorize as
> > > > > I view leaving users logged in as a security risk. Apparently Twitter 
> > > > > does
> > > > > not:
>
> > > > >http://code.google.com/p/twitter-api/issues/detail?id=1070
>
> > > > > On Mon, Dec 28, 2009 at 17:13, Andy Freeman  
> > > > > wrote:
> > > > > > > Then use authenticate. It accomplishes the same effect of 
> > > > > > > authorize.
>
> > > > > > Does it?  My notes say that authenticate leaves the user logged into
> > > > > > twitter if they weren't before and that authorize doesn't.
>
> > > > > > For my purposes, I'd like to force the user to specify their twitter
> > > > > > account and password even if they're already logged in and not 
> > > > > > change
> > > > > > their login state (as far as twitter is concerned) at all.
>
> > > > > > I can imagine folks who'd like to allow users to quickly authorize 
> > > > > > the
> > > > > > use of the logged in account (if any)
>
> > > > > > I can't imagine anyone who'd want to change the user's logged in
> > > > > > state.
>
> > > > > > On Dec 27, 6:08 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > Then use authenticate. It accomplishes the same effect of 
> > > > > > > authorize.
>
> > > > > > > On Sun, Dec 27, 2009 at 17:42, Justyn  
> > > > > > > wrote:
> > > > > > > > Thanks Abraham - I understand this is the current limitation, 
> > > > > > > > however
> > > > > > > > I think there is a need for the foce_login to be available with 
> > > > > > > > the
> > > > > > > > authorize function. The authorize landing page is confusing to 
> > > > > > > > users
> > > > > > > > who want to sign-in with an account that is different from their
> > > > > > > > latest session. The "sign-out" option is not obvious to users. 
> > > > > > > > This is
> > > > > > > > based on user feedback, and I don't think we're the only ones 
> > > > > > > > having
> > > > > > > > this issue.
>
> > > > > > > > On Dec 27, 3:39 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > > > force_login=true only works onhttps://
> > > > > > twitter.com/oauth/authenticatenot
> > > > > > > > > onhttps://twitter.com/oauth/authorize.
>
> > > > > > > > > On Sat, Dec 26, 2009 at 23:23, el moro 
> > > > > > > > > 
> > > > > > > > wrote:
> > > 

[twitter-dev] Re: oAuth Authenticate vs. Authorize (force_login)

[Andy Freeman]

> Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> args} this stuff is working very well for me;) Thank you for your
> hint.

While that "works", I think that it shouldn't.

(1) I don't think that it's a legal url because it has two '?'s.
(2) force_login=true isn't part of the signed arguments so it should
be rejected.  (The whole point of signing is to block man-in-the-
middle attacks that alter arguments.)

I haven't tried including force_login=true in the signed arguments.
Are you saying that it doesn't work?  If so, I'd say that that's a
bug, as is the above.

Thanks,
-andy



On Dec 28, 9:41 pm, el moro  wrote:
> Nice =>https://twitter.com/oauth/authenticate?force_login=true?{signed
> args} this stuff is working very well for me;) Thank you for your
> hint.
>
> Axel
>
> On 29 Dez., 03:21, Andy Freeman  wrote:
>
>
>
> > > The difference (to my understanding) is that Authenticate does not
> > > authorize the app.
>
> > Huh?
>
> > Whether I use authorize or authenticate, my app can tweet etc on the
> > user's behalf.
>
> > What, exactly, do you think that authenticate and authorize do?  I
> > think that both can give my application a token that I can use to take
> > actions on the user's behalf.  I think that both do some sort of login
> > or check before doing so.
>
> > The difference that I see is in how twitter presents its questions
> > regarding the account that is allowing my application to do its thing.
>
> > That, and the bit that authenticate leaves folks logged in to twitter.
>
> > On Dec 28, 5:27 pm, Justyn  wrote:
>
> > > The difference (to my understanding) is that Authenticate does not
> > > authorize the app. We need to have the app authorized but want to give
> > > the user the chance to choose which account to login with (and
> > > Authorize).
>
> > > Ideally, twitter state would not be effected, and user could authorize
> > > an app with desired account (regardless of session) without clicking
> > > "sign out".
>
> > > Justyn
>
> > > On Dec 28, 5:36 pm, Abraham Williams <4bra...@gmail.com> wrote:
>
> > > > That is true. Authenticate currently leaves the user logged in.
>
> > > > I would prefer that get fixed rather then adding force_login to 
> > > > authorize as
> > > > I view leaving users logged in as a security risk. Apparently Twitter 
> > > > does
> > > > not:
>
> > > >http://code.google.com/p/twitter-api/issues/detail?id=1070
>
> > > > On Mon, Dec 28, 2009 at 17:13, Andy Freeman  
> > > > wrote:
> > > > > > Then use authenticate. It accomplishes the same effect of authorize.
>
> > > > > Does it?  My notes say that authenticate leaves the user logged into
> > > > > twitter if they weren't before and that authorize doesn't.
>
> > > > > For my purposes, I'd like to force the user to specify their twitter
> > > > > account and password even if they're already logged in and not change
> > > > > their login state (as far as twitter is concerned) at all.
>
> > > > > I can imagine folks who'd like to allow users to quickly authorize the
> > > > > use of the logged in account (if any)
>
> > > > > I can't imagine anyone who'd want to change the user's logged in
> > > > > state.
>
> > > > > On Dec 27, 6:08 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > Then use authenticate. It accomplishes the same effect of authorize.
>
> > > > > > On Sun, Dec 27, 2009 at 17:42, Justyn  
> > > > > > wrote:
> > > > > > > Thanks Abraham - I understand this is the current limitation, 
> > > > > > > however
> > > > > > > I think there is a need for the foce_login to be available with 
> > > > > > > the
> > > > > > > authorize function. The authorize landing page is confusing to 
> > > > > > > users
> > > > > > > who want to sign-in with an account that is different from their
> > > > > > > latest session. The "sign-out" option is not obvious to users. 
> > > > > > > This is
> > > > > > > based on user feedback, and I don't think we're the only ones 
> > > > > > > having
> > > > > > > this issue.
>
> > > > > > > On Dec 27, 3:39 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > > force_login=true only works onhttps://
> > > > > twitter.com/oauth/authenticatenot
> > > > > > > > onhttps://twitter.com/oauth/authorize.
>
> > > > > > > > On Sat, Dec 26, 2009 at 23:23, el moro 
> > > > > > > > 
> > > > > > > wrote:
> > > > > > > > > Hi, i'd like to use force_login too in my new Rails 
> > > > > > > > > application.
> > > > > This
> > > > > > > > > parameter seems to be buggy. For me it' s not working too.
>
> > > > > > > > > On 24 Dez., 05:18, Justyn  wrote:
> > > > > > > > > > Hi guys - just wanted to make sure this stayed on the 
> > > > > > > > > > radar. I
> > > > > > > imagine
> > > > > > > > > > others would like to use force_login for the Authorize 
> > > > > > > > > > function?
>
> > > > > > > > > > On Dec 22, 4:46 pm, Justyn  wrote:
>
> > > > > > > > > > > We've found it necessary to use the force_login method for
> > > > > > > Authorize
> > > > > > > > > > > 

[twitter-dev] Re: Rate limited on search query

[netlatch]

Thanks Brian

On Dec 29, 1:40 pm, Brian Sutorius  wrote:
> Your IP and username are probably whitelisted for the REST API, which
> does not cover search queries. For more information, 
> seehttp://apiwiki.twitter.com/Rate-limiting. To request whitelisting for
> the Search API, please write to a...@twitter.com with a link to your
> application and a brief explanation of how it works and why it needs
> to be whitelisted.
>
> Brian
>
> On Dec 29, 10:25 am, netlatch  wrote:
>
> > My app IP address and twitter @username are white-listed yet I am
> > still rate limited on search queries. What am I missing? The search is
> > being conducted from a sub-domain but I assume sub-domains are include
> > with the main domain when white-listed. Am I wrong?
>
> > netlatch

[twitter-dev] Re: Rate limited on search query

[Brian Sutorius]

Your IP and username are probably whitelisted for the REST API, which
does not cover search queries. For more information, see
http://apiwiki.twitter.com/Rate-limiting . To request whitelisting for
the Search API, please write to a...@twitter.com with a link to your
application and a brief explanation of how it works and why it needs
to be whitelisted.

Brian

On Dec 29, 10:25 am, netlatch  wrote:
> My app IP address and twitter @username are white-listed yet I am
> still rate limited on search queries. What am I missing? The search is
> being conducted from a sub-domain but I assume sub-domains are include
> with the main domain when white-listed. Am I wrong?
>
> netlatch

[twitter-dev] Rate limited on search query

[netlatch]

My app IP address and twitter @username are white-listed yet I am
still rate limited on search queries. What am I missing? The search is
being conducted from a sub-domain but I assume sub-domains are include
with the main domain when white-listed. Am I wrong?

netlatch

Re: [twitter-dev] Ambiguity with 401 error response code

[Raffi Krikorian]

hi eric.

yup - you've hit it right on the head.  one of the main initiatives in us
starting to version our API is so that we can really consolidate and make
our error codes consistent.  unfortunately, for legacy compatibility
reasons, we can't change the second case to have a 402 error and we will
have to keep it as a 401.

what you could do is parse the response that comes back in the 401, however.
 in the case that your password is wrong, the error should be

"Could not authenticate you."

for basic auth and OAuth. the second case has an error of

"Not authorized"

On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip <
e...@marcoullier.com> wrote:

> We're trying to build some logic into our data collector and we've
> been fighting with an issue for a while involving the 401
> "Unauthorized" error code.
>
> There are two instances where I can get this response
>
> 1) Bad credentials.  I try to log in with an invalid username or
> password.
> 2) I don't have access to a specific user's private account.
>
> The former can be a real problem for a user.  I changed my password a
> few weeks ago and forgot that I was using it for whitelisted REST API
> access.  Querying three times in rapid succession with a bad password
> causes a temporary lockdown of a user's account.  I was querying once
> per second and locked the account for a five days.  This is an account-
> level issue and the proper way to deal with this from our perspective
> is to immediately sleep the poller for 30 minutes and send an alert
> about bad credentials.
>
> This is completely different than if someone I'm following has taken
> their account private.  In this case, sleeping for 30 minutes (or any
> amount of time, really) is overkill.  Unless I'm querying for a single
> person over and over, there's no reason to pause before moving onto
> the next rule that I'm querying for.
>
> Unfortunately, we have no way to disambiguate between the two 401s and
> we're forced to either lock someone's account (ignoring 401s) or
> severely reduce their polling efficiency (acting on 401s).
>
> Best case would be to break these two error conditions out into
> separate error codes.  Perhaps a 401 for bad credentials and a 402 for
> lack of authorization for a specific piece of content.
>
> Please let know if I've overlooked something that would help me
> disambiguate the use cases in the current system.
>
> Thanks!
> Eric
>
>
>


-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Streaming API Client DNS TTL issue

[John Kalucki]

I've noticed a handful of Twitter Streaming API clients that are not
honoring the DNS Time To Live (TTL). If your client is currently
connected to 128.121.146.231, you certainly have an issue with
ignoring the TTL. If you have restarted your client in the last few
weeks, but are connected to another IP address, you may or may not
have this issue. Clients ignoring DNS TTL will be subject to
unpredictable outages as we shift load between clusters.

In any case, the prudent developer would test the client stack against
a test DNS record and validate that the TTL is honored correctly.

I added the following to the Wiki:

"
Test that your client process honors the DNS Time To live (TTL). Some
stacks will cache a resolved address for the duration of the process
and will not pick up DNS changes within the proscribed TTL. Such
aggressive caching will lead to service disruptions on your client as
Twitter shifts load between IP addresses.
"

-John Kalucki
http://twitter.com/jkalucki
Services, Twitter Inc.

[twitter-dev] Re: Your opinion about a twitter search filtering procedure.

[humbucker]

Solved, answer is in the post if other people got the same question

On 29 déc, 15:54, humbucker  wrote:
> Raffi,
>
> Right, that's exactly what I'm trying to do with Curl and Php,
> everything works if I want to list timeline, @replies but nothing show
> up about the followers...
> Check my post 
> :http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> Really strange cause the XML itself is correct.
> Thank you sincerly
>
> On 29 déc, 14:50, Raffi Krikorian  wrote:
>
> > true - searching through all your followers is going to be untenable pretty
> > quickly if you are using the twitter search API, however.  you may need to
> > just get all the tweets from your followers, and then do the search
> > yourself...
>
> > On Tue, Dec 29, 2009 at 5:37 AM, humbucker wrote:
>
> > > because this syntax doesnt allow me to perfoarm a search in it, that
> > > will list all my followers status and information only...
> > > wrong?
>
> > > On 29 déc, 14:35, Raffi Krikorian  wrote:
> > > > why not just usehttp://
> > > apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f...
> > > > ?
>
> > > > On Tue, Dec 29, 2009 at 2:50 AM, humbucker  > > >wrote:
>
> > > > > Hello,
>
> > > > > As I would like to display only the tweets from my followers, I
> > > > > thought this solution could do the trick
>
> > >http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID
> > > ..
>
> > > > > What's your opinion keeping in mind I will maybe one day have 500
> > > > > followers or more to perform a search from?
> > > > > Has an url a maximum lenght?
> > > > > What would be the best way to do an alternative then?
>
> > > > > Many many thanks
>
> > > > --
> > > > Raffi Krikorian
> > > > Twitter Platform Teamhttp://twitter.com/raffi
>
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi

[twitter-dev] Re: Can't retrieve latest followers's tweets

[humbucker]

Ok I've found, the generated xml is not organizeed the same way,
instead of ...it's 

Cheers!

On 29 déc, 14:35, humbucker  wrote:
> Hi!
>
> The code below just produce a blank result when trying to list my
> followers's latest tweet
> N.B. It's working if I filter something else in the query, like
> @replies, timeline users or so...
>
>  $login = "myID:myPW";
> $curl_conn = curl_init();
> $request = "https://twitter.com/statuses/followers/myID.xml?count=9";;
> curl_setopt($curl_conn, CURLOPT_URL, $request); //URL to connect to
> curl_setopt($curl_conn, CURLOPT_GET, 1); //Use GET method
> curl_setopt($curl_conn, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
> curl_setopt($curl_conn, CURLOPT_USERPWD, $login); //Set u/p
> curl_setopt($curl_conn, CURLOPT_SSL_VERIFYPEER, false);
> curl_setopt($curl_conn, CURLOPT_RETURNTRANSFER, 1);
> $output = curl_exec($curl_conn);
> $tweeters = new SimpleXMLElement($output);
>
> $latesttweets = count($tweeters);
>
> foreach ($tweeters->status as $twit1) {
>
> echo "http://www.twitter.com/";, 
> $twit1->user->screen_name,"\" target=\"_blank\">
> \"twitter_followers\" src=\"", $twit1->user->profile_image_url, "\"
> title=\"", $twit1->name, "\" />\n";
> echo "";}
> curl_close($curl_conn);
>
> Thank you!

[twitter-dev] Re: Your opinion about a twitter search filtering procedure.

[humbucker]

Raffi,

Right, that's exactly what I'm trying to do with Curl and Php,
everything works if I want to list timeline, @replies but nothing show
up about the followers...
Check my post :
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/33cc308a59ecb43a

Really strange cause the XML itself is correct.
Thank you sincerly

On 29 déc, 14:50, Raffi Krikorian  wrote:
> true - searching through all your followers is going to be untenable pretty
> quickly if you are using the twitter search API, however.  you may need to
> just get all the tweets from your followers, and then do the search
> yourself...
>
> On Tue, Dec 29, 2009 at 5:37 AM, humbucker wrote:
>
>
>
> > because this syntax doesnt allow me to perfoarm a search in it, that
> > will list all my followers status and information only...
> > wrong?
>
> > On 29 déc, 14:35, Raffi Krikorian  wrote:
> > > why not just usehttp://
> > apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f...
> > > ?
>
> > > On Tue, Dec 29, 2009 at 2:50 AM, humbucker  > >wrote:
>
> > > > Hello,
>
> > > > As I would like to display only the tweets from my followers, I
> > > > thought this solution could do the trick
>
> >http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID
> > ..
>
> > > > What's your opinion keeping in mind I will maybe one day have 500
> > > > followers or more to perform a search from?
> > > > Has an url a maximum lenght?
> > > > What would be the best way to do an alternative then?
>
> > > > Many many thanks
>
> > > --
> > > Raffi Krikorian
> > > Twitter Platform Teamhttp://twitter.com/raffi
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi

Re: [twitter-dev] Twitter Developer Q&A on Stack Overflow

[Jonathan Markwell]

Hi Zac,

These are some great points!

On Tue, Dec 29, 2009 at 1:01 PM, Zac Bowling  wrote:
> Basic questions get answered usually here just as long as they are not
> obvious questions on the Wiki. :-)

That doesn't really mean they shouldn't be answered at all. If new
members of the community are primarily directed to Stack Overflow
junior members of the community can gain recognition while learning
more for themselves by answering these kinds of of questions.

> Stack Overflow has a lot of overflow (no pun) with other development
> communities. You see a lot of questions around how to use the twitter API
> with specific languages or frameworks on Stack Overflow rather then the
> twitter API specifically itself.

And those questions also come here. The organisation of Stack Overflow
means that once properly tagged they shouldn't cause too much noise
for the rest of us.

> More often then not, this list is usually filled with people that understand
> their platform well enough and past the basics of the API and are trying to
> maintain or develop larger twitter related projects these days. The
> questions that come up are usually around the lesser accessed/less trivial
> APIs (streaming, social graph, and oauth to some extent) or by people that
> need understanding on rate limiting or white-listing with the API that only
> the twitter devs maybe able to help with, or sometimes just to discuss
> changes in the API or bugs that popup as things happen.
> Stack Overflow is awesome but it's not a good platform for what goes on
> here.

I'm not saying Stack Overflow can replace everything that goes on
here. My concern is that if the Q&A  / support posts continue grow in
volume the list may become too noisy for some of the higher level
discussion to continue effectively.

Jon.


> Zac Bowling
>
> On Tue, Dec 29, 2009 at 4:13 AM, Jonathan Markwell 
> wrote:
>>
>> Hi Ken, Andrew,
>>
>> Thank you for your thoughts! I had considered a Stack Exchange and
>> have set up a couple of experimental Q&A communities using it.  After
>> the seeing what the Android and Adbobe teams are doing I think it
>> makes much more sense to keep the programming discussion in one place
>> on and avoid splitting the community.
>>
>> I've not experienced the problems new developers may have with getting
>> started with Stack Overflow. While I'd like to think of the Twitter
>> Platform as being a perfect starting point for new developers trying
>> there hand at using web APIs, I think a key skill all programmers need
>> to learn first is how to find existing solutions to problems. If a new
>> developer finds it difficult participating in Stack Overflow vs.
>> posting to a mailing list, they are likely to become a very high
>> maintenance member of the community.  Unfortunately looking back at
>> the archives of this group it looks like many newbie questions go
>> unanswered. That is far less likely to happen on Stack Overflow as
>> there are incentives for people of all levels of expertise to help
>> each other.
>>
>> Stack Overflow looks like a great opportunity to bring developer
>> communities together which will ultimately be better for all of us.
>> We've seen a number of language specific questions pop up here that
>> the wider Stack Overflow community would probably do a much better job
>> of answering. In addition, comparing discussions around different
>> platforms side by side in Stack Overflow may increasingly influence
>> developers trying to decide which platform (Twitter/Facebook/LinkedIn)
>> to integrate with first. I think we'd fair very well here and the more
>> open competition between the communities will help highlight areas
>> which should be prioritised for improvement.
>>
>> Jon.
>>
>> On Tue, Dec 29, 2009 at 6:30 AM, Ken Dobruskin  wrote:
>> >> It seems like creating a stackexchange would just split the support
>> >> power.
>> >
>> > +1, totally.
>> >
>> >> One issue I've noticed with Stackoverflow is it is harder for new
>> >> developers to participate where as the barrier for entry on Google
>> >> Groups is
>> >> just having an email address.
>> > Some email groups can be very tough on newbies and this can change (ie,
>> > get
>> > worse) over time as there are no posted rules/policy. In my view, stack
>> > exchange is well conceived to avoid the trap of a harsh expert user
>> > playing
>> > the troll and shutting out new users. There is also a place for rules,
>> > and
>> > if desired a meta-Q&A for discussion of the discussion. I agree though
>> > that
>> > it should be up to Twitter to provide this environment.
>> >
>> > Ken
>> >
>> >
>> >> Abraham
>> > On Mon, Dec 28, 2009 at 21:40, Ken Dobruskin  wrote:
>> >
>> > Jonathan,
>> >
>> > Good points and initiative.
>> >
>> >>
>> >> I do not believe Twitter have the resources to recreate the success of
>> >> Stack Overflow for Q&A purposes.
>> >
>> > Have you considered setting up a Twitter Dev Q&A beta site on
>> > stackexchange.com? I have, and someone probably cou

[twitter-dev] Ambiguity with 401 error response code

[Eric Marcoullier @ Gnip]

We're trying to build some logic into our data collector and we've
been fighting with an issue for a while involving the 401
"Unauthorized" error code.

There are two instances where I can get this response

1) Bad credentials.  I try to log in with an invalid username or
password.
2) I don't have access to a specific user's private account.

The former can be a real problem for a user.  I changed my password a
few weeks ago and forgot that I was using it for whitelisted REST API
access.  Querying three times in rapid succession with a bad password
causes a temporary lockdown of a user's account.  I was querying once
per second and locked the account for a five days.  This is an account-
level issue and the proper way to deal with this from our perspective
is to immediately sleep the poller for 30 minutes and send an alert
about bad credentials.

This is completely different than if someone I'm following has taken
their account private.  In this case, sleeping for 30 minutes (or any
amount of time, really) is overkill.  Unless I'm querying for a single
person over and over, there's no reason to pause before moving onto
the next rule that I'm querying for.

Unfortunately, we have no way to disambiguate between the two 401s and
we're forced to either lock someone's account (ignoring 401s) or
severely reduce their polling efficiency (acting on 401s).

Best case would be to break these two error conditions out into
separate error codes.  Perhaps a 401 for bad credentials and a 402 for
lack of authorization for a specific piece of content.

Please let know if I've overlooked something that would help me
disambiguate the use cases in the current system.

Thanks!
Eric

[twitter-dev] Tranform created_at to timezone

[invadermedia]

I want to change the tweet created_at time from the xml that I
retrieve from user_timeline to adjust to the correct time for it's
timezone.

I'm guessing I have to use xslt fn:adjust-date-to-timezone. Does
anyone have any recommendations?

Re: [twitter-dev] Re: Your opinion about a twitter search filtering procedure.

[Raffi Krikorian]

true - searching through all your followers is going to be untenable pretty
quickly if you are using the twitter search API, however.  you may need to
just get all the tweets from your followers, and then do the search
yourself...

On Tue, Dec 29, 2009 at 5:37 AM, humbucker wrote:

> because this syntax doesnt allow me to perfoarm a search in it, that
> will list all my followers status and information only...
> wrong?
>
> On 29 déc, 14:35, Raffi Krikorian  wrote:
> > why not just usehttp://
> apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f...
> > ?
> >
> > On Tue, Dec 29, 2009 at 2:50 AM, humbucker  >wrote:
> >
> > > Hello,
> >
> > > As I would like to display only the tweets from my followers, I
> > > thought this solution could do the trick
> >
> > >
> http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID
> ..
> >
> > > What's your opinion keeping in mind I will maybe one day have 500
> > > followers or more to perform a search from?
> > > Has an url a maximum lenght?
> > > What would be the best way to do an alternative then?
> >
> > > Many many thanks
> >
> > --
> > Raffi Krikorian
> > Twitter Platform Teamhttp://twitter.com/raffi
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: Your opinion about a twitter search filtering procedure.

[humbucker]

because this syntax doesnt allow me to perfoarm a search in it, that
will list all my followers status and information only...
wrong?

On 29 déc, 14:35, Raffi Krikorian  wrote:
> why not just 
> usehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f...
> ?
>
> On Tue, Dec 29, 2009 at 2:50 AM, humbucker wrote:
>
> > Hello,
>
> > As I would like to display only the tweets from my followers, I
> > thought this solution could do the trick
>
> >http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID..
>
> > What's your opinion keeping in mind I will maybe one day have 500
> > followers or more to perform a search from?
> > Has an url a maximum lenght?
> > What would be the best way to do an alternative then?
>
> > Many many thanks
>
> --
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi

[twitter-dev] Can't retrieve latest followers's tweets

[humbucker]

Hi!

The code below just produce a blank result when trying to list my
followers's latest tweet
N.B. It's working if I filter something else in the query, like
@replies, timeline users or so...

https://twitter.com/statuses/followers/myID.xml?count=9";;
curl_setopt($curl_conn, CURLOPT_URL, $request); //URL to connect to
curl_setopt($curl_conn, CURLOPT_GET, 1); //Use GET method
curl_setopt($curl_conn, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($curl_conn, CURLOPT_USERPWD, $login); //Set u/p
curl_setopt($curl_conn, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($curl_conn, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($curl_conn);
$tweeters = new SimpleXMLElement($output);

$latesttweets = count($tweeters);

foreach ($tweeters->status as $twit1) {

echo "http://www.twitter.com/";, $twit1-
>user->screen_name,"\" target=\"_blank\">user->profile_image_url, "\"
title=\"", $twit1->name, "\" />\n";
echo "";}
curl_close($curl_conn);

Thank you!

Re: [twitter-dev] Your opinion about a twitter search filtering procedure.

[Raffi Krikorian]

why not just use
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0followers
?

On Tue, Dec 29, 2009 at 2:50 AM, humbucker wrote:

> Hello,
>
> As I would like to display only the tweets from my followers, I
> thought this solution could do the trick
>
> >>
> http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID1)+OR+(followerID2)+OR+...
>
> What's your opinion keeping in mind I will maybe one day have 500
> followers or more to perform a search from?
> Has an url a maximum lenght?
> What would be the best way to do an alternative then?
>
> Many many thanks
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] Twitter Developer Q&A on Stack Overflow

[Zac Bowling]

Basic questions get answered usually here just as long as they are not
obvious questions on the Wiki. :-)

Stack Overflow has a lot of overflow (no pun) with other development
communities. You see a lot of questions around how to use the twitter API
with specific languages or frameworks on Stack Overflow rather then the
twitter API specifically itself.

More often then not, this list is usually filled with people that understand
their platform well enough and past the basics of the API and are trying to
maintain or develop larger twitter related projects these days. The
questions that come up are usually around the lesser accessed/less trivial
APIs (streaming, social graph, and oauth to some extent) or by people that
need understanding on rate limiting or white-listing with the API that only
the twitter devs maybe able to help with, or sometimes just to discuss
changes in the API or bugs that popup as things happen.

Stack Overflow is awesome but it's not a good platform for what goes on
here.

Zac Bowling

On Tue, Dec 29, 2009 at 4:13 AM, Jonathan Markwell
wrote:

> Hi Ken, Andrew,
>
> Thank you for your thoughts! I had considered a Stack Exchange and
> have set up a couple of experimental Q&A communities using it.  After
> the seeing what the Android and Adbobe teams are doing I think it
> makes much more sense to keep the programming discussion in one place
> on and avoid splitting the community.
>
> I've not experienced the problems new developers may have with getting
> started with Stack Overflow. While I'd like to think of the Twitter
> Platform as being a perfect starting point for new developers trying
> there hand at using web APIs, I think a key skill all programmers need
> to learn first is how to find existing solutions to problems. If a new
> developer finds it difficult participating in Stack Overflow vs.
> posting to a mailing list, they are likely to become a very high
> maintenance member of the community.  Unfortunately looking back at
> the archives of this group it looks like many newbie questions go
> unanswered. That is far less likely to happen on Stack Overflow as
> there are incentives for people of all levels of expertise to help
> each other.
>
> Stack Overflow looks like a great opportunity to bring developer
> communities together which will ultimately be better for all of us.
> We've seen a number of language specific questions pop up here that
> the wider Stack Overflow community would probably do a much better job
> of answering. In addition, comparing discussions around different
> platforms side by side in Stack Overflow may increasingly influence
> developers trying to decide which platform (Twitter/Facebook/LinkedIn)
> to integrate with first. I think we'd fair very well here and the more
> open competition between the communities will help highlight areas
> which should be prioritised for improvement.
>
> Jon.
>
> On Tue, Dec 29, 2009 at 6:30 AM, Ken Dobruskin  wrote:
> >> It seems like creating a stackexchange would just split the support
> power.
> >
> > +1, totally.
> >
> >> One issue I've noticed with Stackoverflow is it is harder for new
> >> developers to participate where as the barrier for entry on Google
> Groups is
> >> just having an email address.
> > Some email groups can be very tough on newbies and this can change (ie,
> get
> > worse) over time as there are no posted rules/policy. In my view, stack
> > exchange is well conceived to avoid the trap of a harsh expert user
> playing
> > the troll and shutting out new users. There is also a place for rules,
> and
> > if desired a meta-Q&A for discussion of the discussion. I agree though
> that
> > it should be up to Twitter to provide this environment.
> >
> > Ken
> >
> >
> >> Abraham
> > On Mon, Dec 28, 2009 at 21:40, Ken Dobruskin  wrote:
> >
> > Jonathan,
> >
> > Good points and initiative.
> >
> >>
> >> I do not believe Twitter have the resources to recreate the success of
> >> Stack Overflow for Q&A purposes.
> >
> > Have you considered setting up a Twitter Dev Q&A beta site on
> > stackexchange.com? I have, and someone probably could, but I thought I'd
> > wait and see what the official Twitter development platform had to offer
> > before doing that!
> >
> > Ken
> >
> >
> > 
> > Windows Live: Keep your friends up to date with what you do online.
> >
> >
> > --
> > Abraham Williams | Awesome Lists | http://awesomeli.st
> > Project | Intersect | http://intersect.labs.poseurtech.com
> > Hacker | http://abrah.am | http://twitter.com/abraham
> > This email is: [ ] shareable [x] ask first [ ] private.
> > Sent from Madison, WI, United States
> > 
> > Windows Live: Make it easier for your friends to see what you’re up to on
> > Facebook.
>
>
>
> --
> Jonathan Markwell
> Engineer | Founder | Connector
>
> Inuda Innovations Ltd, Brighton, UK
>
> Web application development & support
> Twitter & Facebook integration specialists
> http://inuda.com
>

Re: [twitter-dev] Twitter Developer Q&A on Stack Overflow

[Jonathan Markwell]

Hi Ken, Andrew,

Thank you for your thoughts! I had considered a Stack Exchange and
have set up a couple of experimental Q&A communities using it.  After
the seeing what the Android and Adbobe teams are doing I think it
makes much more sense to keep the programming discussion in one place
on and avoid splitting the community.

I've not experienced the problems new developers may have with getting
started with Stack Overflow. While I'd like to think of the Twitter
Platform as being a perfect starting point for new developers trying
there hand at using web APIs, I think a key skill all programmers need
to learn first is how to find existing solutions to problems. If a new
developer finds it difficult participating in Stack Overflow vs.
posting to a mailing list, they are likely to become a very high
maintenance member of the community.  Unfortunately looking back at
the archives of this group it looks like many newbie questions go
unanswered. That is far less likely to happen on Stack Overflow as
there are incentives for people of all levels of expertise to help
each other.

Stack Overflow looks like a great opportunity to bring developer
communities together which will ultimately be better for all of us.
We've seen a number of language specific questions pop up here that
the wider Stack Overflow community would probably do a much better job
of answering. In addition, comparing discussions around different
platforms side by side in Stack Overflow may increasingly influence
developers trying to decide which platform (Twitter/Facebook/LinkedIn)
to integrate with first. I think we'd fair very well here and the more
open competition between the communities will help highlight areas
which should be prioritised for improvement.

Jon.

On Tue, Dec 29, 2009 at 6:30 AM, Ken Dobruskin  wrote:
>> It seems like creating a stackexchange would just split the support power.
>
> +1, totally.
>
>> One issue I've noticed with Stackoverflow is it is harder for new
>> developers to participate where as the barrier for entry on Google Groups is
>> just having an email address.
> Some email groups can be very tough on newbies and this can change (ie, get
> worse) over time as there are no posted rules/policy. In my view, stack
> exchange is well conceived to avoid the trap of a harsh expert user playing
> the troll and shutting out new users. There is also a place for rules, and
> if desired a meta-Q&A for discussion of the discussion. I agree though that
> it should be up to Twitter to provide this environment.
>
> Ken
>
>
>> Abraham
> On Mon, Dec 28, 2009 at 21:40, Ken Dobruskin  wrote:
>
> Jonathan,
>
> Good points and initiative.
>
>>
>> I do not believe Twitter have the resources to recreate the success of
>> Stack Overflow for Q&A purposes.
>
> Have you considered setting up a Twitter Dev Q&A beta site on
> stackexchange.com? I have, and someone probably could, but I thought I'd
> wait and see what the official Twitter development platform had to offer
> before doing that!
>
> Ken
>
>
> 
> Windows Live: Keep your friends up to date with what you do online.
>
>
> --
> Abraham Williams | Awesome Lists | http://awesomeli.st
> Project | Intersect | http://intersect.labs.poseurtech.com
> Hacker | http://abrah.am | http://twitter.com/abraham
> This email is: [ ] shareable [x] ask first [ ] private.
> Sent from Madison, WI, United States
> 
> Windows Live: Make it easier for your friends to see what you’re up to on
> Facebook.



-- 
Jonathan Markwell
Engineer | Founder | Connector

Inuda Innovations Ltd, Brighton, UK

Web application development & support
Twitter & Facebook integration specialists
http://inuda.com

Organising the world's first events for the Twitter developer Community
http://TwitterDeveloperNest.com

Providing a nice little place to work in the middle of Brighton -
http://theskiff.org

Measuring your brand's visibility on the social web - http://HowSociable.com

mob: 07766 021 485 | tel: 01273 704 549 | fax: 01273 376 953
skype: jlmarkwell | twitter: http://twitter.com/jot

[twitter-dev] Your opinion about a twitter search filtering procedure.

[humbucker]

Hello,

As I would like to display only the tweets from my followers, I
thought this solution could do the trick

>> http://search.twitter.com/search.atom?q=(searchTerm)&from=(followerID1)+OR+(followerID2)+OR+
>>  ...

What's your opinion keeping in mind I will maybe one day have 500
followers or more to perform a search from?
Has an url a maximum lenght?
What would be the best way to do an alternative then?

Many many thanks