[twitter-dev] Re: Net::Twitter dev release with Lists API support

[Jesse Stay]

How do I get on the List beta?  I'd really like to use it.  Who do I pay and
how much?

Jesse

On Fri, Oct 23, 2009 at 10:47 PM, Marc Mims  wrote:

>
> I uploaded a development release of Net::Twitter to CPAN with Lists API
> support.  If you're a perl developer and you're on the Lists beta,
> please test it and give me some feedback.
>
> Download it here:
> http://search.cpan.org/~mmims/Net-Twitter-3.07999_01/
>
> For documentation see:
>
>perldoc Net::Twitter::Role::API::Lists
>
> You'll need to include the API::Lists trait:
>
>my $nt = Net::Twitter->new(traits => ['API::Lists', ...], ...);
>
> You can always use the "user" parameter as the first placeholder
> argument to any of the API calls.  Any or all of the parameters included
> in the API URL can be passed as placeholder arguments.  Additional
> arguments are passed by name in a HASH ref as the final argument.  Any
> or all parameters can be passed in the HASH ref.
>
> For example, these calls are equivalent:
>
>my $list = $nt->create_list(perl_api =>
>{ name => 'test', mode => private }
>);
>
>my $list = $nt->create_list({
>user => 'perl_api',
>name => 'test',
>mode => 'private',
>});
>
> In my own testing, I've noticed that the update_list call always returns
> a 500 status, even though it succeeds.  That's probably a Twitter bug
> that will be worked out.
>
> The Lists API support is experimental.  It will very likely change
> before a final release.  Feedback welcome.
>
>-Marc
>

[twitter-dev] Re: Deprecation Notice: pagination on several methods is being replaced with cursoring on October 26, 2009

[DustyReagan]

Bump.

Anyone know if page deprecation still scheduled to happen on Oct.
26th?


On Oct 22, 3:17 am, Rich  wrote:
> I hope not, Apple are being especially slow at approving my update at
> the moment that includes the cursor changes!
>
> On Oct 22, 3:20 am, DustyReagan  wrote:
>
>
>
> > Is page deprecation still scheduled to happen on Oct. 26th?
>
> > Is this deprecation happening on all methods that have the cursor
> > parameter enabled?
>
> > -Dusty
>
> > On Oct 8, 5:26 am, Kyle Mulka  wrote:
>
> > > Will thepageparameter on /statuses/user_timeline (or on any of the
> > > other timeline methods) be deprecated as 
> > > well?https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-statuses-us...
>
> > > I've noticed a lot of failures on /statuses/user_timeline recently.
> > > Instead of thepageparameter, is it better to use max_id?
>
> > > --
> > > Kyle Mulkahttp://twilk.com-putyour friends faces on your Twitter 
> > > background
>
> > > On Sep 24, 8:47 pm, Alex Payne  wrote:
>
> > > > Hi,
>
> > > > Recently, we documented a new pagination mechanism for our "social
> > > > graph" methods, /friends/ids and /followers/ids. Traditional
> > > >page-based pagination doesn't dovetail with our recent backend
> > > > changes, and we've now exposed acursor-based pagination mechanism
> > > > that's far more reliable.
>
> > > > Today, we've documented that this new pagination mechanism is also
> > > > available for the /statuses/friends and /statuses/followers methods.
> > > > With that change, we're setting a hard deprecation date for
> > > > traditional pagination on these four methods: October 26th, 2009.
> > > > That's over a month from now.
>
> > > > Once deprecated, we'll simply ignore the "page" parameter if it's sent
> > > > by a client, and you'll get the default number of items for the method
> > > > you're calling.
>
> > > > For more information, 
> > > > seehttp://apiwiki.twitter.com/Twitter-API-Documentation. Thanks.
>
> > > > --
> > > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

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

[TjL]

On Tue, Oct 20, 2009 at 5:13 PM, Chad Etzel  wrote:

> Just to follow up. We have determined that this is a bug and the
> engineering team is working to figure out how this snuck in. I'm
> afraid I don't have an ETA on a fix, but we are working on it.

FYI "how this snuck in" is fairly suspicious, given that there had
been some fairly prominent use of whitespace just a few hours before
this "bug" appeared:

http://favrd.textism.com/tweet/4998900426

http://favrd.textism.com/tweet/4999223282

I'm not alone in thinking the timing is suspicious, especially if this
wasn't some quickly undoable change. It works one way for years, then
"accidentally" gets changed but you can't figure out what happened or
how to undo it?

TjL

[twitter-dev] Net::Twitter dev release with Lists API support

[Marc Mims]

I uploaded a development release of Net::Twitter to CPAN with Lists API
support.  If you're a perl developer and you're on the Lists beta,
please test it and give me some feedback.

Download it here:
http://search.cpan.org/~mmims/Net-Twitter-3.07999_01/

For documentation see:

perldoc Net::Twitter::Role::API::Lists

You'll need to include the API::Lists trait:

my $nt = Net::Twitter->new(traits => ['API::Lists', ...], ...);

You can always use the "user" parameter as the first placeholder
argument to any of the API calls.  Any or all of the parameters included
in the API URL can be passed as placeholder arguments.  Additional
arguments are passed by name in a HASH ref as the final argument.  Any
or all parameters can be passed in the HASH ref.

For example, these calls are equivalent:

my $list = $nt->create_list(perl_api =>
{ name => 'test', mode => private }
);

my $list = $nt->create_list({
user => 'perl_api',
name => 'test',
mode => 'private',
});

In my own testing, I've noticed that the update_list call always returns
a 500 status, even though it succeeds.  That's probably a Twitter bug
that will be worked out.

The Lists API support is experimental.  It will very likely change
before a final release.  Feedback welcome.

-Marc

[twitter-dev] Favs not being recorded, or are seriously delayed

[Tim Haines]

Hey guys,

It seems when visiting twitter.com, and clicking on the star to add tweets
to my favorites list, the favs aren't actually showing in my favorites list.
(even 5 mins later)

Just mentioning it so it gets on the radar if it's not already.

Cheers,

Tim.

[twitter-dev] Re: API 140 character truncation change?

[Naveen Ayyagari]

+1 agreed

On Oct 23, 2009, at 7:20 PM, Dewald Pretorius wrote:



Instead of all of us having to do fancy tap-dances, the proper
solution is for Twitter to issue an error response when a sent tweet
is rejected for whatever reason.

Dewald

On Oct 23, 7:58 pm, AJ Chen  wrote:
then, comparing the front part (without url at the end) of the  
status is

probably sufficient. -aj



On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius  
 wrote:



You cannot compare the status sent with the status returned when the
status contains an URL. The returned status contains Twitter's own
bit.ly shortened URL instead of the URL your status sent had.



Dewald



On Oct 23, 6:24 pm, AJ Chen  wrote:
I noticed this behavior a long time ago (may be a month) and  
reported the
problem on this list, but it did not get any response from the  
api team.

I
thought it was a bug, but just realized yesterday that the api  
probably
ignores 140+ chars status update intentionally. but' I'm not sure  
this is
the policy or temporary tactic to reduce workload on api. it  
would be

good
that api team can clasify on this issue. to check if this happens  
or not,
you can compare the status sent to api and the status returned  
from api

in

your application code.
 -aj



On Fri, Oct 23, 2009 at 1:51 PM, Naveen  wrote:



Here are two threads related to this issue.


http://groups.google.com/group/twitter-development-talk/browse_thread 
.

..


http://groups.google.com/group/twitter-development-talk/browse_thread 
.

..


It is an inconvenient change, not because they changed it, but  
because

they did not announce that the change was happening.



On Oct 21, 5:37 am, Dave Sherohman  wrote:

On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
Has anyone else noticed a change in the way that the 140  
character
limit is enforced via the API? I noticed a change sometime  
between

the
13th and the 16th that is now causing all my 140+ character  
posts

to

be rejected by the API.
Also a side note is that the api is not returning errors, they

return

proper responses however they are the proper response for the

current
status of the account, not the new status that was just  
attempted

to

be posted.



My users first reported issues arising from this on the 15th,

although I

didn't identify the cause until the 17th, at which point I asked

about
it in #Net::Twitter and Marc Mims brought the question here  
under the
subject line "Bug? Updates > 140 characters return success with  
prior
update  payload".  See the discussion under that thread for  
more on

it,

but the overall upshot is:



- This is an intentional (if poorly-announced) change, not a bug.
- Status updates are known to be getting silently rejected in  
this
  manner both due to exceeding 140 characters and due to  
violation of

  the expanded "no duplicates" policy.
- Twitter has not stated whether there are any additional

circumstances
  beyond those two cases in which updates will be silently  
rejected.
- Twitter has not stated any plans regarding adding an  
indicator for

  when a "200 OK" status update has, in fact, been rejected.



I am attempting to compensate for this change by checking the

returned
status ID against the previous highest-seen ID to determine  
whether

the
status returned with the "200 OK" response is a new one or the  
user's
pre-existing status.  This seems to work, but does not indicate  
the

reason for the silent failure, so I can't report the cause to my

users.

Andy Freeman has mentioned that, in the case of rejection due to
duplication, this is also unsatisfactory in that it does not  
allow

him

to identify the original status which was duplicated.



--
Dave Sherohman



--
AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
Palo Alto, CA


--
AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
Palo Alto, CA

[twitter-dev] Re: API 140 character truncation change?

[Dewald Pretorius]

Instead of all of us having to do fancy tap-dances, the proper
solution is for Twitter to issue an error response when a sent tweet
is rejected for whatever reason.

Dewald

On Oct 23, 7:58 pm, AJ Chen  wrote:
> then, comparing the front part (without url at the end) of the status is
> probably sufficient. -aj
>
>
>
> On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius  wrote:
>
> > You cannot compare the status sent with the status returned when the
> > status contains an URL. The returned status contains Twitter's own
> > bit.ly shortened URL instead of the URL your status sent had.
>
> > Dewald
>
> > On Oct 23, 6:24 pm, AJ Chen  wrote:
> > > I noticed this behavior a long time ago (may be a month) and reported the
> > > problem on this list, but it did not get any response from the api team.
> > I
> > > thought it was a bug, but just realized yesterday that the api probably
> > > ignores 140+ chars status update intentionally. but' I'm not sure this is
> > > the policy or temporary tactic to reduce workload on api. it would be
> > good
> > > that api team can clasify on this issue. to check if this happens or not,
> > > you can compare the status sent to api and the status returned from api
> > in
> > > your application code.
> > >  -aj
>
> > > On Fri, Oct 23, 2009 at 1:51 PM, Naveen  wrote:
>
> > > > Here are two threads related to this issue.
>
> > > >http://groups.google.com/group/twitter-development-talk/browse_thread.
> > ..
>
> > > >http://groups.google.com/group/twitter-development-talk/browse_thread.
> > ..
>
> > > > It is an inconvenient change, not because they changed it, but because
> > > > they did not announce that the change was happening.
>
> > > > On Oct 21, 5:37 am, Dave Sherohman  wrote:
> > > > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
> > > > > > Has anyone else noticed a change in the way that the 140 character
> > > > > > limit is enforced via the API? I noticed a change sometime between
> > the
> > > > > > 13th and the 16th that is now causing all my 140+ character posts
> > to
> > > > > > be rejected by the API.
> > > > > > Also a side note is that the api is not returning errors, they
> > return
> > > > > > proper responses however they are the proper response for the
> > current
> > > > > > status of the account, not the new status that was just attempted
> > to
> > > > > > be posted.
>
> > > > > My users first reported issues arising from this on the 15th,
> > although I
> > > > > didn't identify the cause until the 17th, at which point I asked
> > about
> > > > > it in #Net::Twitter and Marc Mims brought the question here under the
> > > > > subject line "Bug? Updates > 140 characters return success with prior
> > > > > update  payload".  See the discussion under that thread for more on
> > it,
> > > > > but the overall upshot is:
>
> > > > > - This is an intentional (if poorly-announced) change, not a bug.
> > > > > - Status updates are known to be getting silently rejected in this
> > > > >   manner both due to exceeding 140 characters and due to violation of
> > > > >   the expanded "no duplicates" policy.
> > > > > - Twitter has not stated whether there are any additional
> > circumstances
> > > > >   beyond those two cases in which updates will be silently rejected.
> > > > > - Twitter has not stated any plans regarding adding an indicator for
> > > > >   when a "200 OK" status update has, in fact, been rejected.
>
> > > > > I am attempting to compensate for this change by checking the
> > returned
> > > > > status ID against the previous highest-seen ID to determine whether
> > the
> > > > > status returned with the "200 OK" response is a new one or the user's
> > > > > pre-existing status.  This seems to work, but does not indicate the
> > > > > reason for the silent failure, so I can't report the cause to my
> > users.
> > > > > Andy Freeman has mentioned that, in the case of rejection due to
> > > > > duplication, this is also unsatisfactory in that it does not allow
> > him
> > > > > to identify the original status which was duplicated.
>
> > > > > --
> > > > > Dave Sherohman
>
> > > --
> > > AJ Chen, PhD
> > > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
> > > Palo Alto, CA
>
> --
> AJ Chen, PhD
> Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
> Palo Alto, CA

[twitter-dev] Re: API 140 character truncation change?

[AJ Chen]

then, comparing the front part (without url at the end) of the status is
probably sufficient. -aj

On Fri, Oct 23, 2009 at 3:07 PM, Dewald Pretorius  wrote:

>
> You cannot compare the status sent with the status returned when the
> status contains an URL. The returned status contains Twitter's own
> bit.ly shortened URL instead of the URL your status sent had.
>
> Dewald
>
> On Oct 23, 6:24 pm, AJ Chen  wrote:
> > I noticed this behavior a long time ago (may be a month) and reported the
> > problem on this list, but it did not get any response from the api team.
> I
> > thought it was a bug, but just realized yesterday that the api probably
> > ignores 140+ chars status update intentionally. but' I'm not sure this is
> > the policy or temporary tactic to reduce workload on api. it would be
> good
> > that api team can clasify on this issue. to check if this happens or not,
> > you can compare the status sent to api and the status returned from api
> in
> > your application code.
> >  -aj
> >
> >
> >
> > On Fri, Oct 23, 2009 at 1:51 PM, Naveen  wrote:
> >
> > > Here are two threads related to this issue.
> >
> > >http://groups.google.com/group/twitter-development-talk/browse_thread.
> ..
> >
> > >http://groups.google.com/group/twitter-development-talk/browse_thread.
> ..
> >
> > > It is an inconvenient change, not because they changed it, but because
> > > they did not announce that the change was happening.
> >
> > > On Oct 21, 5:37 am, Dave Sherohman  wrote:
> > > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
> > > > > Has anyone else noticed a change in the way that the 140 character
> > > > > limit is enforced via the API? I noticed a change sometime between
> the
> > > > > 13th and the 16th that is now causing all my 140+ character posts
> to
> > > > > be rejected by the API.
> > > > > Also a side note is that the api is not returning errors, they
> return
> > > > > proper responses however they are the proper response for the
> current
> > > > > status of the account, not the new status that was just attempted
> to
> > > > > be posted.
> >
> > > > My users first reported issues arising from this on the 15th,
> although I
> > > > didn't identify the cause until the 17th, at which point I asked
> about
> > > > it in #Net::Twitter and Marc Mims brought the question here under the
> > > > subject line "Bug? Updates > 140 characters return success with prior
> > > > update  payload".  See the discussion under that thread for more on
> it,
> > > > but the overall upshot is:
> >
> > > > - This is an intentional (if poorly-announced) change, not a bug.
> > > > - Status updates are known to be getting silently rejected in this
> > > >   manner both due to exceeding 140 characters and due to violation of
> > > >   the expanded "no duplicates" policy.
> > > > - Twitter has not stated whether there are any additional
> circumstances
> > > >   beyond those two cases in which updates will be silently rejected.
> > > > - Twitter has not stated any plans regarding adding an indicator for
> > > >   when a "200 OK" status update has, in fact, been rejected.
> >
> > > > I am attempting to compensate for this change by checking the
> returned
> > > > status ID against the previous highest-seen ID to determine whether
> the
> > > > status returned with the "200 OK" response is a new one or the user's
> > > > pre-existing status.  This seems to work, but does not indicate the
> > > > reason for the silent failure, so I can't report the cause to my
> users.
> > > > Andy Freeman has mentioned that, in the case of rejection due to
> > > > duplication, this is also unsatisfactory in that it does not allow
> him
> > > > to identify the original status which was duplicated.
> >
> > > > --
> > > > Dave Sherohman
> >
> > --
> > AJ Chen, PhD
> > Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
> > Palo Alto, CA




-- 
AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.org
http://web2express.org
Palo Alto, CA

[twitter-dev] Re: API 140 character truncation change?

[Dewald Pretorius]

You cannot compare the status sent with the status returned when the
status contains an URL. The returned status contains Twitter's own
bit.ly shortened URL instead of the URL your status sent had.

Dewald

On Oct 23, 6:24 pm, AJ Chen  wrote:
> I noticed this behavior a long time ago (may be a month) and reported the
> problem on this list, but it did not get any response from the api team. I
> thought it was a bug, but just realized yesterday that the api probably
> ignores 140+ chars status update intentionally. but' I'm not sure this is
> the policy or temporary tactic to reduce workload on api. it would be good
> that api team can clasify on this issue. to check if this happens or not,
> you can compare the status sent to api and the status returned from api in
> your application code.
>  -aj
>
>
>
> On Fri, Oct 23, 2009 at 1:51 PM, Naveen  wrote:
>
> > Here are two threads related to this issue.
>
> >http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> >http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> > It is an inconvenient change, not because they changed it, but because
> > they did not announce that the change was happening.
>
> > On Oct 21, 5:37 am, Dave Sherohman  wrote:
> > > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
> > > > Has anyone else noticed a change in the way that the 140 character
> > > > limit is enforced via the API? I noticed a change sometime between the
> > > > 13th and the 16th that is now causing all my 140+ character posts to
> > > > be rejected by the API.
> > > > Also a side note is that the api is not returning errors, they return
> > > > proper responses however they are the proper response for the current
> > > > status of the account, not the new status that was just attempted to
> > > > be posted.
>
> > > My users first reported issues arising from this on the 15th, although I
> > > didn't identify the cause until the 17th, at which point I asked about
> > > it in #Net::Twitter and Marc Mims brought the question here under the
> > > subject line "Bug? Updates > 140 characters return success with prior
> > > update  payload".  See the discussion under that thread for more on it,
> > > but the overall upshot is:
>
> > > - This is an intentional (if poorly-announced) change, not a bug.
> > > - Status updates are known to be getting silently rejected in this
> > >   manner both due to exceeding 140 characters and due to violation of
> > >   the expanded "no duplicates" policy.
> > > - Twitter has not stated whether there are any additional circumstances
> > >   beyond those two cases in which updates will be silently rejected.
> > > - Twitter has not stated any plans regarding adding an indicator for
> > >   when a "200 OK" status update has, in fact, been rejected.
>
> > > I am attempting to compensate for this change by checking the returned
> > > status ID against the previous highest-seen ID to determine whether the
> > > status returned with the "200 OK" response is a new one or the user's
> > > pre-existing status.  This seems to work, but does not indicate the
> > > reason for the silent failure, so I can't report the cause to my users.
> > > Andy Freeman has mentioned that, in the case of rejection due to
> > > duplication, this is also unsatisfactory in that it does not allow him
> > > to identify the original status which was duplicated.
>
> > > --
> > > Dave Sherohman
>
> --
> AJ Chen, PhD
> Chair, Semantic Web SIG, sdforum.orghttp://web2express.org
> Palo Alto, CA

[twitter-dev] Re: API 140 character truncation change?

[AJ Chen]

I noticed this behavior a long time ago (may be a month) and reported the
problem on this list, but it did not get any response from the api team. I
thought it was a bug, but just realized yesterday that the api probably
ignores 140+ chars status update intentionally. but' I'm not sure this is
the policy or temporary tactic to reduce workload on api. it would be good
that api team can clasify on this issue. to check if this happens or not,
you can compare the status sent to api and the status returned from api in
your application code.
 -aj

On Fri, Oct 23, 2009 at 1:51 PM, Naveen  wrote:

>
> Here are two threads related to this issue.
>
> http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868
>
> http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e#
>
> It is an inconvenient change, not because they changed it, but because
> they did not announce that the change was happening.
>
> On Oct 21, 5:37 am, Dave Sherohman  wrote:
> > On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
> > > Has anyone else noticed a change in the way that the 140 character
> > > limit is enforced via the API? I noticed a change sometime between the
> > > 13th and the 16th that is now causing all my 140+ character posts to
> > > be rejected by the API.
> > > Also a side note is that the api is not returning errors, they return
> > > proper responses however they are the proper response for the current
> > > status of the account, not the new status that was just attempted to
> > > be posted.
> >
> > My users first reported issues arising from this on the 15th, although I
> > didn't identify the cause until the 17th, at which point I asked about
> > it in #Net::Twitter and Marc Mims brought the question here under the
> > subject line "Bug? Updates > 140 characters return success with prior
> > update  payload".  See the discussion under that thread for more on it,
> > but the overall upshot is:
> >
> > - This is an intentional (if poorly-announced) change, not a bug.
> > - Status updates are known to be getting silently rejected in this
> >   manner both due to exceeding 140 characters and due to violation of
> >   the expanded "no duplicates" policy.
> > - Twitter has not stated whether there are any additional circumstances
> >   beyond those two cases in which updates will be silently rejected.
> > - Twitter has not stated any plans regarding adding an indicator for
> >   when a "200 OK" status update has, in fact, been rejected.
> >
> > I am attempting to compensate for this change by checking the returned
> > status ID against the previous highest-seen ID to determine whether the
> > status returned with the "200 OK" response is a new one or the user's
> > pre-existing status.  This seems to work, but does not indicate the
> > reason for the silent failure, so I can't report the cause to my users.
> > Andy Freeman has mentioned that, in the case of rejection due to
> > duplication, this is also unsatisfactory in that it does not allow him
> > to identify the original status which was duplicated.
> >
> > --
> > Dave Sherohman
>



-- 
AJ Chen, PhD
Chair, Semantic Web SIG, sdforum.org
http://web2express.org
Palo Alto, CA

[twitter-dev] Re: OAuth without user interaction

[ryan alford]

If you have a user's username and password, you can do OAuth without
user intervention. I did it using .Net to do screen-scraping for a
desktop application to get the PIN. I was able to do everything
necessary to get the access token without anything from the user other
than their username and password.

However, Twitter does not condone this and could/would blacklist an IP
if this process is used.

Ryan


On Oct 23, 2009, at 5:18 PM, Chris Babcock 
wrote:

>
> On Fri, 23 Oct 2009 16:32:25 -0400
> ryan alford  wrote:
>
>> It is possible to do OAuth without user interaction if you have their
>> username and password, but this is frowned upon by Twitter and could
>> get your IP blacklisted.
>
> You do need user interaction to get initial approval for a token,
> after
> which you can reuse a token until it is revoked. There is a chance
> (Has
> this happened recently?) that a token may expire without obvious
> reason, but they are supposed to be reusable.
>
> There's no replacement for testing, which has been absent in my shop
> recently because of the churn on the API... which I'm hoping will be
> addressed by versioning.
>
> Chris Babcock

[twitter-dev] Re: OAuth without user interaction

[Chris Babcock]

On Fri, 23 Oct 2009 16:32:25 -0400
ryan alford  wrote:

> It is possible to do OAuth without user interaction if you have their
> username and password, but this is frowned upon by Twitter and could
> get your IP blacklisted.

You do need user interaction to get initial approval for a token, after
which you can reuse a token until it is revoked. There is a chance (Has
this happened recently?) that a token may expire without obvious
reason, but they are supposed to be reusable. 

There's no replacement for testing, which has been absent in my shop
recently because of the churn on the API... which I'm hoping will be
addressed by versioning.

Chris Babcock

[twitter-dev] Re: API Proposal : Bulk fetch of user details

[Waldron Faulkner]

I'm completely on board with any strategy that will simplify (or
especially amplify) the amount of graph data I can get. I had a
discussion recently with Ryan where he indicated an openness to ideas
of this sort because there is (he says) no getting around the 20K rate
limits... an idea I find preposterous, but OK... whatever! So I'll be
very interested to see if we can gain any traction on this front. I
definitely can't get the amount of data I need to keep my app
reasonably fresh with the rate limits available.

- Waldron
GraphEdge.com

On Oct 22, 2:52 pm, Harshad RJ  wrote:
> Hi,
>
> I am collating the thoughts in this thread [1] into a proposal to improve
> the efficiency of social-graphing applications.
>
> A common API access pattern for social-graphing applications seems to be:
>
> 1. Get the friend/follower ids of a user with [*friends/ids*] or [*
> followers/ids*]
> 2. Get user details one at a time with [*users/show*]
>
> (This approach saves on bandwidth by not using the [*statuses/friends*]
> method, as that would return redundant info when traversing a network)
>
> Now, since [*users/show*] is not a paginated API, it is easily possible to
> save bandwidth and connection overhead by clubbing multiple requests in one
> call. For a social-graphing application, the amount of user information
> needed is minimal.
>
> For example, the following amount of information would be sufficient for my
> application [1]:
>
> 
> 
>   1401881
>   dougw
>   1031
>   293
>   Sun Mar 18 06:42:26 + 2007
>   3390
>   
>     Tue Apr 07 22:52:51 + 2009
>   
> 
>
> This is significantly smaller than the data returned by [*users/show*].
>
> To prevent misuse of the new API the following could be enforced:
> 1. A maximum limit on number of users that can be queried in one request
> 2. Rate limiting based on number of users requested. For example, if (N)
> users' details were requested in one call, count it as (N/2) requests. This
> will provide incentive for using the new API as well as dettering misuse.
>
> [1]http://groups.google.com/group/twitter-development-talk/browse_thread...
> [2]http://twinkler.in
>
> cheers,
> --
> Harshad RJhttp://hrj.wikidot.com

[twitter-dev] Re: API 140 character truncation change?

[Naveen]

Here are two threads related to this issue.
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cd95ce07be341223/66c66de585383868#66c66de585383868
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3d6a727892710d5e#

It is an inconvenient change, not because they changed it, but because
they did not announce that the change was happening.

On Oct 21, 5:37 am, Dave Sherohman  wrote:
> On Tue, Oct 20, 2009 at 07:37:03AM -0700, James Tymann wrote:
> > Has anyone else noticed a change in the way that the 140 character
> > limit is enforced via the API? I noticed a change sometime between the
> > 13th and the 16th that is now causing all my 140+ character posts to
> > be rejected by the API.
> > Also a side note is that the api is not returning errors, they return
> > proper responses however they are the proper response for the current
> > status of the account, not the new status that was just attempted to
> > be posted.
>
> My users first reported issues arising from this on the 15th, although I
> didn't identify the cause until the 17th, at which point I asked about
> it in #Net::Twitter and Marc Mims brought the question here under the
> subject line "Bug? Updates > 140 characters return success with prior
> update  payload".  See the discussion under that thread for more on it,
> but the overall upshot is:
>
> - This is an intentional (if poorly-announced) change, not a bug.
> - Status updates are known to be getting silently rejected in this
>   manner both due to exceeding 140 characters and due to violation of
>   the expanded "no duplicates" policy.
> - Twitter has not stated whether there are any additional circumstances
>   beyond those two cases in which updates will be silently rejected.
> - Twitter has not stated any plans regarding adding an indicator for
>   when a "200 OK" status update has, in fact, been rejected.
>
> I am attempting to compensate for this change by checking the returned
> status ID against the previous highest-seen ID to determine whether the
> status returned with the "200 OK" response is a new one or the user's
> pre-existing status.  This seems to work, but does not indicate the
> reason for the silent failure, so I can't report the cause to my users.
> Andy Freeman has mentioned that, in the case of rejection due to
> duplication, this is also unsatisfactory in that it does not allow him
> to identify the original status which was duplicated.
>
> --
> Dave Sherohman

[twitter-dev] Re: Welcome the the Twitter Development Talk

[ryan alford]

You could also use this
http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses
friends

if
you wanted to get the latest status of the friends.

On Fri, Oct 23, 2009 at 4:34 PM, ryan alford wrote:

> Let's not do any looking for ourselves.
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends 
> ids
>
>  Just
> incase you have any questions about API methods, you should probably check
> out the API wiki first since it lists ALL API methods and gives a
> description of what they actually do.
>
> http://apiwiki.twitter.com/Twitter-API-Documentation
>
>
> On Fri, Oct 23, 2009 at 12:38 PM, Gaurav Shaha wrote:
>
>> My requirement is to get "Following" list not "Follower" list.
>>
>> On Fri, Oct 23, 2009 at 9:33 PM, ryan alford wrote:
>>
>>> http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers 
>>> ids
>>>
>>>
>>> On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha 
>>> wrote:
>>>
 Hey can you help?
 I want the list of following of a specific user using php. Kindly revert
 solution if you know it.


 On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti 
 wrote:

>
> I meant to send that to list owner. Sorry.




 --
 Warm Regards,
 Gaurav Shaha
 9823359549.


 "All Persons have weakness..
 But each will have one particular Strength..
 That will overwrite all weakness,
 if u believe in URSELF"

>>>
>>>
>>
>>
>> --
>> Warm Regards,
>> Gaurav Shaha
>> 9823359549.
>>
>>
>> "All Persons have weakness..
>> But each will have one particular Strength..
>> That will overwrite all weakness,
>> if u believe in URSELF"
>>
>
>

[twitter-dev] Re: Welcome the the Twitter Development Talk

[ryan alford]

Let's not do any looking for ourselves.

http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends
ids

Just
incase you have any questions about API methods, you should probably check
out the API wiki first since it lists ALL API methods and gives a
description of what they actually do.

http://apiwiki.twitter.com/Twitter-API-Documentation

On Fri, Oct 23, 2009 at 12:38 PM, Gaurav Shaha wrote:

> My requirement is to get "Following" list not "Follower" list.
>
> On Fri, Oct 23, 2009 at 9:33 PM, ryan alford wrote:
>
>> http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers 
>> ids
>>
>>
>> On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha wrote:
>>
>>> Hey can you help?
>>> I want the list of following of a specific user using php. Kindly revert
>>> solution if you know it.
>>>
>>>
>>> On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti wrote:
>>>

 I meant to send that to list owner. Sorry.
>>>
>>>
>>>
>>>
>>> --
>>> Warm Regards,
>>> Gaurav Shaha
>>> 9823359549.
>>>
>>>
>>> "All Persons have weakness..
>>> But each will have one particular Strength..
>>> That will overwrite all weakness,
>>> if u believe in URSELF"
>>>
>>
>>
>
>
> --
> Warm Regards,
> Gaurav Shaha
> 9823359549.
>
>
> "All Persons have weakness..
> But each will have one particular Strength..
> That will overwrite all weakness,
> if u believe in URSELF"
>

[twitter-dev] Re: OAuth without user interaction

[ryan alford]

It is possible to do OAuth without user interaction if you have their
username and password, but this is frowned upon by Twitter and could get
your IP blacklisted.

OAuth is the only way to get the source to be your app.

Ryan

On Fri, Oct 23, 2009 at 2:22 PM, Marcos  wrote:

>
> In development of a twitter app, we are using unique twitter account
> to post updates in twitter.
> User and password its in config files server side.
>
> We need post tweets with "from appname" modified and not just "API"
> like now happens.
> With a little research we know "&source=appname" param its deprecated,
> or still some way to work with this in new apps?
> In other hand, ¿we can use Oauth without user interaction?
>
> ¿Some experience about this?
>

[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?

[away3D]

Is this planned already? Please do something about this, using a proxy
is a sloppy way of just communicating with the API directly.

-Pete

On Oct 21, 1:31 pm, orian  wrote:
> Now that api.twitter.com has gone live, can we please have a less
> restrictive crossdomain.xml so that Flash apps can access the API
> without requiring the use of a proxy? This was being planned more than
> a year and a half 
> ago:http://groups.google.com/group/twitter-development-talk/browse_thread...

[twitter-dev] OAuth without user interaction

[Marcos]

In development of a twitter app, we are using unique twitter account
to post updates in twitter.
User and password its in config files server side.

We need post tweets with "from appname" modified and not just "API"
like now happens.
With a little research we know "&source=appname" param its deprecated,
or still some way to work with this in new apps?
In other hand, ¿we can use Oauth without user interaction?

¿Some experience about this?

[twitter-dev] Re: Welcome the the Twitter Development Talk

[Gaurav Shaha]

My requirement is to get "Following" list not "Follower" list.

On Fri, Oct 23, 2009 at 9:33 PM, ryan alford wrote:

> http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers 
> ids
>
>
> On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha wrote:
>
>> Hey can you help?
>> I want the list of following of a specific user using php. Kindly revert
>> solution if you know it.
>>
>> On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti wrote:
>>
>>>
>>> I meant to send that to list owner. Sorry.
>>
>>
>>
>>
>> --
>> Warm Regards,
>> Gaurav Shaha
>> 9823359549.
>>
>>
>> "All Persons have weakness..
>> But each will have one particular Strength..
>> That will overwrite all weakness,
>> if u believe in URSELF"
>>
>
>


-- 
Warm Regards,
Gaurav Shaha
9823359549.


"All Persons have weakness..
But each will have one particular Strength..
That will overwrite all weakness,
if u believe in URSELF"

[twitter-dev] Re: New behaviour for statuses/update API call for 141+ char sized messages and duplicates?

[Kevin Menard]

Hi,

I'm seeing the same thing that Ole is.  Twitter is not truncating the
status, but rather returning the last correctly updated status.

--
Kevin

On Oct 16, 4:58 am, janole  wrote:
> According to my tests, messages will not be truncated anymore!
>
> Instead, you will get the most recentstatusupdateas a reply.
>
> Is this a bug or feature?
>
> Also, it seems as if the API now checks for duplicates in your
> "backlog" of statuses and not just you most recent tweet.
>
> Previously, only the last tweet was checked:
>
> - Last tweet "test"
> - Send new tweet with "status=test" will return the oldstatus(with
> the old status_id)
>
> but if you had something like this:
>
> Last tweet "Hello, world."
> Second last tweet "test"
>
> Then you were able to create a new tweet with "status=test"!
>
> This is not possible at the moment.
>
> Bug or feature?
>
> I'm getting a lot of complaints from my Twitter client users who
> apparently experience both of these new "behaviours" or "bugs" (long
> tweets fail, duplicates fail.)
>
> Ole @ mobileways.de
> On Twitter:http://twitter.com/janole
>
> On Oct 15, 8:26 pm, Josh Roesslein  wrote:
>
>
>
> > If you send a message longer than 140 twitter will truncate it and set
> > the truncate value on thestatusto True.
> > For duplicates it will just ignore thestatus.
>
> > Josh
>
> > On Thu, Oct 15, 2009 at 1:20 PM, janole  wrote:
>
> > > Hi,
>
> > > I just figured out that when calling statuses/updatewith a text
> > > longer than 140 chars, the reply of that API call will be 200 OK with
> > > the laststatusof the user.
>
> > > Wouldn't it be better to return some sort of error message?
>
> > > The same seems to be happening when sending a duplicate tweet.
>
> > > Ole
>
> > > --
> > > Jan Ole Suhr
> > > s...@mobileways.de
> > > On Twitter:http://twitter.com/janole

[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?

[Arpit Mathur]

+1 !
This could really enable some awesome web clients for Twitter.

On Oct 21, 1:31 pm, orian  wrote:
> Now that api.twitter.com has gone live, can we please have a less
> restrictive crossdomain.xml so that Flash apps can access the API
> without requiring the use of a proxy? This was being planned more than
> a year and a half 
> ago:http://groups.google.com/group/twitter-development-talk/browse_thread...

[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?

[yoni]

Seriously. I'm no Flash developer, but I know more than a few Flash/
Flex developers just dying to get some pretty impressive apps out
there. Right now, they're pretty much hamstrung by this limitation.

On Oct 21, 1:31 pm, orian  wrote:
> Now that api.twitter.com has gone live, can we please have a less
> restrictive crossdomain.xml so that Flash apps can access the API
> without requiring the use of a proxy? This was being planned more than
> a year and a half 
> ago:http://groups.google.com/group/twitter-development-talk/browse_thread...

[twitter-dev] Re: Welcome the the Twitter Development Talk

[ryan alford]

http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers
ids

On Fri, Oct 23, 2009 at 2:41 AM, Gaurav Shaha wrote:

> Hey can you help?
> I want the list of following of a specific user using php. Kindly revert
> solution if you know it.
>
>
> On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti wrote:
>
>>
>> I meant to send that to list owner. Sorry.
>
>
>
>
> --
> Warm Regards,
> Gaurav Shaha
> 9823359549.
>
>
> "All Persons have weakness..
> But each will have one particular Strength..
> That will overwrite all weakness,
> if u believe in URSELF"
>

[twitter-dev] Re: Welcome the the Twitter Development Talk

[Adam Cloud]

I love lamp. (or as we say in my office, i love linq)

[twitter-dev] Re: Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff

[shawninreach]

Ok cool thanks. So is there any method to see what user was authorized
to get to the callback url before rerequesting an access token. Im
using twitter's login to be a single sign on for my site so thats why
im directing them to the authorization page still. I wanted to be able
to check if i had the access token in the db before requesting a new
one just because it seems cleaner, but the only method is just
rerequesting it seems atm. Thanks.

On Oct 23, 6:13 am, ryan alford  wrote:
> If you already have an access token for that user, then you don't need
> to send them to the authorization page.
>
> You cannot get the username and password they just put into the
> authorization page.
>
> If you want the username that they entered into the authorization
> page, when you request the access token, the username is returned as
> one of the Http headers.
>
> On Oct 23, 2009, at 5:33 AM, shawninreach 
> wrote:
>
>
>
> > On the callback page im trying to figure out a way to differenciate
> > when a user logged in but already has an access token before
> > requesting another one. Most of the methods use the verifycredentials
> > method to make sure you have access to, but you dont know what the
> > user's name is before you call that and you need the access token to
> > do so.
>
> > Login through twitter -> callback app (since they just logged in and
> > didnt allow the app i must already have the access token in the db)
>
> > Login through twitter -> allow access since he/she is registering to a
> > new app -> retrieve access store and login since they did not have an
> > access token before.
>
> > Or on login just rerequest the access token and restore it, which isnt
> > a problem, just seems that there may be a different way to do it.

[twitter-dev] Re: from:user and since_id breaking Search API

[Marc W]

Hello Damon!

I'm not 100% sure I buy this explanation:

1. This problem wasn't happening a day or two ago.

2. I tried executing the query on the command line, and incremented
the since_id by 1 maybe 8-10x ... it just doesn't return any results.

Even weirder is that if I wait 20 minutes, and execute the same query
with the same original since_id, then I might get some of the results,
but not all of them.

Currently, the only solution I can see is to simply never use since_id
and just filter out - on the client - those tweetids I've seen
already.  Seems like a horrible waste of bandwidth and computing
power, and especially strange given that this largely worked a few
days ago, right before some other changes were rolled out that also
seemed to cause a sudden increase in 500-series errors being returned
from the servers and other weirdnesses.


Thanks,
Marc.


On Oct 23, 9:31 pm, Damon Clinkscales  wrote:
> Christopher
>
> To my recollection, for search with since_id to work properly, the
> tweet id must be in the search index.  In this case:
>
> http://search.twitter.com/search?q=+from%3Asilent_tester02
>
> does not yield the "Dinner, movie, drinks." tweet in the index.
>
> As an aside, I did an "exact match search" on that phrase above and it
> returned many results that are not exact matches. But that's a
> separate issue.
>
> You could file an issue about the fact that the results coming back
> are not always consistent, but the first thing I would do is make sure
> that I am using a since_id that actually exists in the search index.
> Granted this can be a bit of a pain to verify this 100% of the time
> because sometimes tweets do not end up in the search index (which
> appears to be the case here). But in my experience, most of the time,
> they do.  So as a test, pick a tweet you know is in the index and make
> some calls with it over a period of time.  See if the results are
> consistent.
>
> Best,
> -damon
> --http://twitter.com/damon
>
> On Tue, Oct 20, 2009 at 9:06 AM, Christopher Warren
>
>
>
>  wrote:
>
> > We have an app that runs searches regularly, and recently stopped
> > receiving new tweets. After investigating we found a search
> > combination that seems to break the search API. Instead of getting a
> > response with no tweets, an .atom request errors and a .json request
> > 404s.
>
> >http://search.twitter.com/search.json?q=from:silent_tester02&since_id...
> >http://search.twitter.com/search.atom?q=from:silent_tester02&since_id...
>
> > Changing the query to not use from:username works as expect, but I've
> > put several usernames in and they all respond the same way. I haven't
> > managed to narrow down the cause of the problem much further than
> > that, but we're handling it in our code by rescuing any failed
> > searches and appending since: with the date of the most recent tweet
> > to the q.
>
> > Any thoughts on what might be causing this would be appreciated.

[twitter-dev] lang parameter in the search api

[fbparis]

The language filter in the search api doesnt seem very accurate.

I've noticed that using Google Translate API for lang detection allow
to refine results very well. So I suggest, if Twitter makes a deal
with google, try to get their lang detection system :) It could be
great for stream api too...

[twitter-dev] Update twitter status error!

[gonandriy]

Good time!
I try to post update status into my twitter account across API, but
this not work.
When I create a new account, and use this authorization data update
for this post successfuly.
When I compare responses from two accounts I find difference beetwen
field "sources".
First account (which not receive updates) have value
'www.twittermail.com'
Second account (which updated successsful) have value
'api.twitter.com'
Is there cause of no display tweets?
I need to update status into first account! Where I have error?

Please, HELP me!

[twitter-dev] Geolocation API Status?

[Allan]

Any updates on the the release of the Geolocation Platform and API?  I
have a few things in the hopper I would like to test.

Thanks,
AL

[twitter-dev] Register an Application fails

[moksahero]

I'm having trouble with http://twitter.com/oauth_clients/new

I always get "Unable to find that client application"
even when I use correct Callback URL that exists and visible from the
Internet.

Is the URL specified in Callback URL needs to produce something?
I wonder this is a bug on twitter's side or not.

Thanks,

Takeshi Amano

[twitter-dev] Re: from:user and since_id breaking Search API

[Dave B]

I'm getting the same issue as Marc and harshavs too.

I'm using since_id to start a search from the last set of resuts but
generally get 0 results most of the time, even though the same search
without since_id yields lots of results.

I could start logging tweet IDs against user IDs, and then work
backwards down the list of past results until I get a since_id that
yields results, but it does seem like a bit of a pain.

This is my first time using the search API so I can't even tell you
when this started happening. It just happens!

For info: search is using negation operators, OR and from:

Dave

On Oct 23, 10:29 am, harshavs  wrote:
> We are experiencing the same thing as Marc. We are not using from:
> though.
> But intermittently it gets tweets in significant number. If I try to
> get the same set again using the since_id for this particular crawl, I
> again get no tweets.
>
> Any Idea on this issue?
>
> Thanks.
>
> On Oct 23, 10:48 am, Marc W  wrote:
>
> > We've started seeing this too.  If we specify a since_id, then
> > periodic refetches will frequently return "no new tweets" (but
> > sometimes they will return new ones).    If we simply drop the
> > since_id, then all new tweets are fetched.
>
> > Some new server optimization thing gone wrong?
>
> > Thanks!
>
> > On Oct 20, 10:06 pm, Christopher Warren 
> > wrote:
>
> > > We have an app that runssearchesregularly, and recently stopped
> > > receiving newtweets. After investigating we found a search
> > > combination that seems to break the search API. Instead of getting a
> > > response withnotweets, an .atom request errors and a .json request
> > > 404s.
>
> > >http://search.twitter.com/search.json?q=from:silent_tester02&since_id..
>
> > > Changing the query to not use from:username works as expect, but I've
> > > put several usernames in and they all respond the same way. I haven't
> > > managed to narrow down the cause of the problem much further than
> > > that, but we're handling it in our code by rescuing any failedsearchesand 
> > > appending since: with the date of the most recent tweet
> > > to the q.
>
> > > Any thoughts on what might be causing this would be appreciated.

[twitter-dev] Re: API Proposal : Bulk fetch of user details

[Oren Rose]

Hi,

I also think that the main issue is not the amount of data, but the
number of API calls.

I vote for bulk API. It may be faster to implement for Twitter guys,
too.

= Oren

On Oct 23, 5:48 am, Harshad RJ  wrote:
> Michael,
>
> On Fri, Oct 23, 2009 at 8:36 AM, Michael Steuer  wrote:
> > I don't see why the data size would make a difference.
>
> If you application needs the complete data, then it won't make a difference.
>
> But for applications that don't need it, it directly impacts bandwidth, and
> depending on the server architecture, it can impact cache hit-ratio, cache
> pressure, buffer quantity and buffer size. Similar considerations are on the
> client side, perhaps to a lesser degree.
>
> Also, on the server side, if lesser amount of data results in a fewer
> table-joins that could make a huge difference.
>
> This is all speculation on my side though and the best guys to know & decide
> are in Twitter.
>
> > I currently request the same amount of data in 100 calls of 1 user, as I
> > would in 1 call of 100 users. My application does require a little more info
> > than yours apparently, and I'm sure every app requires a different subset,
> > so a user object should remain a user object and return all info.
>
> I agree; I am hoping, with a big dose of optimism, that we (social-graph app
> developers and Twitter) can agree upon a common subset, and the ETA for this
> might be earlier than a bulk API with complete user data.
>
> --
> Harshad RJhttp://hrj.wikidot.com

[twitter-dev] Re: from:user and since_id breaking Search API

[Damon Clinkscales]

Christopher

To my recollection, for search with since_id to work properly, the
tweet id must be in the search index.  In this case:

http://search.twitter.com/search?q=+from%3Asilent_tester02

does not yield the "Dinner, movie, drinks." tweet in the index.

As an aside, I did an "exact match search" on that phrase above and it
returned many results that are not exact matches. But that's a
separate issue.

You could file an issue about the fact that the results coming back
are not always consistent, but the first thing I would do is make sure
that I am using a since_id that actually exists in the search index.
Granted this can be a bit of a pain to verify this 100% of the time
because sometimes tweets do not end up in the search index (which
appears to be the case here). But in my experience, most of the time,
they do.  So as a test, pick a tweet you know is in the index and make
some calls with it over a period of time.  See if the results are
consistent.

Best,
-damon
-- 
http://twitter.com/damon

On Tue, Oct 20, 2009 at 9:06 AM, Christopher Warren
 wrote:
>
> We have an app that runs searches regularly, and recently stopped
> receiving new tweets. After investigating we found a search
> combination that seems to break the search API. Instead of getting a
> response with no tweets, an .atom request errors and a .json request
> 404s.
>
> http://search.twitter.com/search.json?q=from:silent_tester02&since_id=4979161317
> http://search.twitter.com/search.atom?q=from:silent_tester02&since_id=4979161317
>
> Changing the query to not use from:username works as expect, but I've
> put several usernames in and they all respond the same way. I haven't
> managed to narrow down the cause of the problem much further than
> that, but we're handling it in our code by rescuing any failed
> searches and appending since: with the date of the most recent tweet
> to the q.
>
> Any thoughts on what might be causing this would be appreciated.

[twitter-dev] Re: updateStatus API

[Guru]

Thanks Tino .. It helped, now I am getting the required link.

~ Guru

On Oct 23, 4:28 am, ElPlatero  wrote:
> Read:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0u...
>
> Annotation für in_reply_to_status_id:
> "Note: This parameter will be ignored unless the author of the tweet
> this parameter references is mentioned within the status text.
> Therefore, you must include @username, where username is the author of
> the referenced tweet, within the update."
>
> Hope this helps.
>
> Tino
>
> On Oct 23, 3:40 am, Guru  wrote:
>
> > Hi,
>
> > To reply for a tweet, I used twitter.updateStatus
> > ("status",inreplyStatusId) api. Reply posted successfully to twitter
> > but it shows only "about 2 minutes ago from Twitter 4j" and it does
> > not show "in reply to 'original tweet'".
> > Am I using the right api or Is there any api to show a link to
> > original tweet?
>
> > Thanks,
> > Guru

[twitter-dev] Re: cursor based paging

[John Kalucki]

Fixed.

On Oct 23, 1:02 am, Pradeep  wrote:
> John,
>
> Please not that the API documentation on this 
> linkhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0f...
> tells the users to use negated values on each subsequent requests.
>
> Please take immediate steps to correct this in the documentation.
>
> Regards,
> Pradeep
>
> On Oct 16, 10:57 am, John Kalucki  wrote:
>
>
>
>
>
> > You are negating the values on subsequent requests. Start with -1
> > (negative 1). Then, just use thecursorvalue exactly as returned.
>
> > Everywhichway, it works just fine.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Oct 15, 2:11 pm, dozykraut  wrote:
>
> > > http:// twitter.com/statuses/followers/username.xml?cursor=-1 gives me
> > > page 1 of my followers list,. When I then request http:// twitter.com/
> > > statuses/followers/username.xml?cursor=-new_cursor_value I get page 1
> > > again.
>
> > > The same happens when I 
> > > requesthttp://twitter.com/statuses/followers.xml?screen_name=username&cursor...
>
> > > So everywhichway - it don't work

[twitter-dev] Re: cursor based paging

[Pradeep]

John,

Please not that the API documentation on this link
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0followers
tells the users to use negated values on each subsequent requests.

Please take immediate steps to correct this in the documentation.

Regards,
Pradeep


On Oct 16, 10:57 am, John Kalucki  wrote:
> You are negating the values on subsequent requests. Start with -1
> (negative 1). Then, just use thecursorvalue exactly as returned.
>
> Everywhichway, it works just fine.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Oct 15, 2:11 pm, dozykraut  wrote:
>
>
>
> > http:// twitter.com/statuses/followers/username.xml?cursor=-1 gives me
> > page 1 of my followers list,. When I then request http:// twitter.com/
> > statuses/followers/username.xml?cursor=-new_cursor_value I get page 1
> > again.
>
> > The same happens when I 
> > requesthttp://twitter.com/statuses/followers.xml?screen_name=username&cursor...
>
> > So everywhichway - it don't work

[twitter-dev] Re: from:user and since_id breaking Search API

[harshavs]

We are experiencing the same thing as Marc. We are not using from:
though.
But intermittently it gets tweets in significant number. If I try to
get the same set again using the since_id for this particular crawl, I
again get no tweets.

Any Idea on this issue?

Thanks.

On Oct 23, 10:48 am, Marc W  wrote:
> We've started seeing this too.  If we specify a since_id, then
> periodic refetches will frequently return "no new tweets" (but
> sometimes they will return new ones).    If we simply drop the
> since_id, then all new tweets are fetched.
>
> Some new server optimization thing gone wrong?
>
> Thanks!
>
> On Oct 20, 10:06 pm, Christopher Warren 
> wrote:
>
> > We have an app that runssearchesregularly, and recently stopped
> > receiving newtweets. After investigating we found a search
> > combination that seems to break the search API. Instead of getting a
> > response withnotweets, an .atom request errors and a .json request
> > 404s.
>
> >http://search.twitter.com/search.json?q=from:silent_tester02&since_id..
>
> > Changing the query to not use from:username works as expect, but I've
> > put several usernames in and they all respond the same way. I haven't
> > managed to narrow down the cause of the problem much further than
> > that, but we're handling it in our code by rescuing any failedsearchesand 
> > appending since: with the date of the most recent tweet
> > to the q.
>
> > Any thoughts on what might be causing this would be appreciated.

[twitter-dev] Re: updateStatus API

[ElPlatero]

Read:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0update

Annotation für in_reply_to_status_id:
"Note: This parameter will be ignored unless the author of the tweet
this parameter references is mentioned within the status text.
Therefore, you must include @username, where username is the author of
the referenced tweet, within the update."

Hope this helps.

Tino

On Oct 23, 3:40 am, Guru  wrote:
> Hi,
>
> To reply for a tweet, I used twitter.updateStatus
> ("status",inreplyStatusId) api. Reply posted successfully to twitter
> but it shows only "about 2 minutes ago from Twitter 4j" and it does
> not show "in reply to 'original tweet'".
> Am I using the right api or Is there any api to show a link to
> original tweet?
>
> Thanks,
> Guru

[twitter-dev] Re: What to do with the access token after you've received it

[ElPlatero]

> Interesting tho, Twitter is putting a lot of trust in the third-party
> app that they won't mismange tokens. At least it's better than basic
> auth. Thanks again.

I don't think so. It's the _user_ who's asked if he trusts that third
party app to not mismanage tokens. Twitter's got nothing to do with
it, if you think about it.

Tino

[twitter-dev] Re: Welcome the the Twitter Development Talk

[Gaurav Shaha]

Hey can you help?
I want the list of following of a specific user using php. Kindly revert
solution if you know it.

On Fri, Oct 23, 2009 at 10:56 AM, Dave Briccetti wrote:

>
> I meant to send that to list owner. Sorry.




-- 
Warm Regards,
Gaurav Shaha
9823359549.


"All Persons have weakness..
But each will have one particular Strength..
That will overwrite all weakness,
if u believe in URSELF"

[twitter-dev] Same list on firther pagination

[Pradeep]

Hi,

I use pagination (using cursor) for getting followers list. But when I
provide the value of cursor on second try, only the first list is
again returned.

Please help.

Thanks,
Pradeep

[twitter-dev] Re: Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff

[ryan alford]

If you already have an access token for that user, then you don't need
to send them to the authorization page.

You cannot get the username and password they just put into the
authorization page.

If you want the username that they entered into the authorization
page, when you request the access token, the username is returned as
one of the Http headers.



On Oct 23, 2009, at 5:33 AM, shawninreach 
wrote:

>
> On the callback page im trying to figure out a way to differenciate
> when a user logged in but already has an access token before
> requesting another one. Most of the methods use the verifycredentials
> method to make sure you have access to, but you dont know what the
> user's name is before you call that and you need the access token to
> do so.
>
> Login through twitter -> callback app (since they just logged in and
> didnt allow the app i must already have the access token in the db)
>
> Login through twitter -> allow access since he/she is registering to a
> new app -> retrieve access store and login since they did not have an
> access token before.
>
> Or on login just rerequest the access token and restore it, which isnt
> a problem, just seems that there may be a different way to do it.

[twitter-dev] Re: Updates to the retweet API payload

[Mark Hawker]

Hi, John. Are you able to update the API documentation with the latest
payloads?

- statuses/retweet and statuses/retweets have an embedded
retweet_details element. Is retweet_id the identifier for the status
of the retweeting user? Shouldn't statuses/retweet return the
retweeted_status element?
- statuses/home_timeline has an embedded retweeted_status element (I'm
with this one)
- statuses/retweeted_by_me, statuses/retweeted_of_me and statuses/
retweeted_to_me are random. Which form will they take?

It's fine that there are two distinct retweet elements, but
documentation doesn't seem to make this very clear.

Best,

On Oct 4, 3:16 pm, John Kalucki  wrote:
> Retweetis an invasive feature with many deep dependency paths. Firm
> dates would be useful, but they aren't possible in this particular
> situation. This makes planning for downstream folks difficult.
>
> I'd be ready for the slight possibility of low-volume retweets mid-to-
> late week, with a high chance the following week, and perhaps a near-
> unity chance of low-volume retweets the week after that. So, for
> critical code, any time now. As for full-roll-out, that would be even
> more of a guessing game.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Oct 4, 6:43 am, Zaudio  wrote:
>
> > Hey John,
>
> > Thanks for that... can you put an earliest date on 'very soon' please
> > - just so I know how long we've got?
>
> > Thanks
>
> > Simon (Zaudio)
>
> > On Oct 3, 8:15 pm, John Kalucki  wrote:
>
> > > There are plans to filter retweets from various resource, see the
> > > documentation. However, it would be most prudent to assume that
> > > retweets will eventually show up everywhere, and handle them
> > > appropriately, or at least tolerate them wherever they are found.
>
> > > They should start appearing in low volumes in all /1/statuses/*
> > > resources on the Streaming API very soon.
>
> > > -John Kaluckihttp://twitter.com/jkalucki
> > > Services, Twitter Inc.
>
> > > On Oct 3, 10:33 am, Zaudio  wrote:
>
> > > > This sounds a lot more sensible...
>
> > > > Importantly, where can we expect this newpayloadto be returned...
> > > > any of the following methods as well?
>
> > > > REST API
> > > > statuses/mentions
> > > > statuses/user
>
> > > > Streaming API/Shadow
>
> > > > I need to know in advance of such an addition to any of these, as
> > > > otherwise the parser on one of our apps gets broken until it's recoded
> > > > to handle theretweetpayload...
>
> > > > or is the ONLY was to get these vie theretweetmethods and the new
> > > > home_timeline ? If so, what about apps that mainly make use of the
> > > > Streaming API for tweets?
>
> > > > Thanks
>
> > > > Simon (Zaudio)

[twitter-dev] Differenciating when a user authenticates user and pass with twitter and when a user allows your app to access their stuff

[shawninreach]

On the callback page im trying to figure out a way to differenciate
when a user logged in but already has an access token before
requesting another one. Most of the methods use the verifycredentials
method to make sure you have access to, but you dont know what the
user's name is before you call that and you need the access token to
do so.

Login through twitter -> callback app (since they just logged in and
didnt allow the app i must already have the access token in the db)

Login through twitter -> allow access since he/she is registering to a
new app -> retrieve access store and login since they did not have an
access token before.

Or on login just rerequest the access token and restore it, which isnt
a problem, just seems that there may be a different way to do it.