[twitter-dev] Re: Comments for the group and Twitter staff

[Matthew Ranney]

Hey Alex, would you consider just giving everybody their money back if they
aren't 100% satisfied?

On Tue, Sep 15, 2009 at 2:16 PM, Alex Payne  wrote:

>
> The main twitter.com site already uses the API in some places. Our
> revised mobile site is built entirely on the API, and our Facebook
> application has been built off our API for some time.
>
> Dogfooding! We support it.
>
> On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
> >
> > I emphatically second and support the idea of twitter.com having to use
> > the API.
> >
> > We had similar quality problems at a place I formerly worked, and they
> > were solved, completely, when such a policy was instituted.
> >
> > Yeah, it puts pressure on the API team and may inconvenience the UI
> > team, or whatever you call them, but in the long run it will be worth
> > it.
> >
> > Side effects that we saw were a simpler, cleaner, more consistent
> > architecture for the whole system, and lower total costs to develop and
> > maintain the system.
> >
> > Bite the bullet and do it now. The longer you wait, the more difficult
> > and expensive it will be.
> >
> > Jim Renkel
> >
> > -Original Message-
> > From: twitter-development-talk@googlegroups.com
> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> > Haneda
> > Sent: Tuesday, September 15, 2009 15:55
> > To: twitter-development-talk@googlegroups.com
> > Subject: [twitter-dev] Re: Comments for the group and Twitter staff
> >
> >
> > Probably too late for this, but perhaps moving forward, it could be
> > done...
> > Twitter.com should move to using their own API.  The tools they use to
> > power their own site should be the same tools we use and rely on.
> >
> > In all reality, this seems a simpler approach, rather than pushing out
> > code for their stuff, and then essentially backporting that to an API,
> > just work on making the API, and then integrate that into the
> > twitter.com site.
> >
> > As far as I can tell, this would solve pretty much every problem the
> > API has, as there can not be a case where twitter is down, but the API
> > is up, or the API is down, and twitter is up.
> >
> > Twitter should be eating their own dog food :)
> > --
> > Scott * If you contact me off list replace talklists@ with scott@ *
> >
> >
> >
>
>
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.
> http://twitter.com/al3x
>

[twitter-dev] Re: Comments for the group and Twitter staff

[PJB]

Would be good if Twitter.com used API to determine, e.g., DM count on
right-side.  Right now it is woefully wrong if we delete DMs via API.

On Sep 15, 2:16 pm, Alex Payne  wrote:
> The main twitter.com site already uses the API in some places. Our
> revised mobile site is built entirely on the API, and our Facebook
> application has been built off our API for some time.
>
> Dogfooding! We support it.
>
>
>
> On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> > I emphatically second and support the idea of twitter.com having to use
> > the API.
>
> > We had similar quality problems at a place I formerly worked, and they
> > were solved, completely, when such a policy was instituted.
>
> > Yeah, it puts pressure on the API team and may inconvenience the UI
> > team, or whatever you call them, but in the long run it will be worth
> > it.
>
> > Side effects that we saw were a simpler, cleaner, more consistent
> > architecture for the whole system, and lower total costs to develop and
> > maintain the system.
>
> > Bite the bullet and do it now. The longer you wait, the more difficult
> > and expensive it will be.
>
> > Jim Renkel
>
> > -Original Message-
> > From: twitter-development-talk@googlegroups.com
> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> > Haneda
> > Sent: Tuesday, September 15, 2009 15:55
> > To: twitter-development-talk@googlegroups.com
> > Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
> > Probably too late for this, but perhaps moving forward, it could be
> > done...
> > Twitter.com should move to using their own API.  The tools they use to
> > power their own site should be the same tools we use and rely on.
>
> > In all reality, this seems a simpler approach, rather than pushing out
> > code for their stuff, and then essentially backporting that to an API,
> > just work on making the API, and then integrate that into the
> > twitter.com site.
>
> > As far as I can tell, this would solve pretty much every problem the
> > API has, as there can not be a case where twitter is down, but the API
> > is up, or the API is down, and twitter is up.
>
> > Twitter should be eating their own dog food :)
> > --
> > Scott * If you contact me off list replace talklists@ with scott@ *
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

I think the important part here is "in some places".  The problem is,  
twitter.com probably has 75% or more of the exposure.  The lowly app  
developer hits a bug in the API, and people say "wtf, works on  
twitter.com, this app sucks".


Good to know that facebook and the mobile site are using the API, but  
I suspect that when you say "some places", while great news, it needs  
to be all places.


If twitter.com is up, and super app for iphone is not, twitter.com  
gets no heat from that, the developer does.


Thank you for the explanation though.
--
Scott * If you contact me off list replace talklists@ with scott@ *

On Sep 15, 2009, at 2:16 PM, Alex Payne wrote:


The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

[twitter-dev] I can't change "following" of mobile option when viewing profile page

[Tam]

Hi,

I work in corporate so I there firewall. Twitter works fine but when I
view someone's page and try to follow them or change mobile
notification options it doesn't work! I get the below messages in
FireBug. I tried using IE, didn't work either.

Firebug's log limit has been reached. %S entries not shown.
Preferences
twttr is not defined
[Break on this error] twttr.form_authenticity_token = 'a...
47b98bf0953486d09d7969a20948f2aaff46e';\nYanniVoices (line 527)
$(".follow-control").isFollowControl is not a function
[Break on this error] $('.follow-control').isFollowControl();
initializePage();\n


Cheers,

Tam

[twitter-dev] Re: Comments for the group and Twitter staff

[Dean Collins]

Hmmm so was does twitter.com work when the API is down.?

How long exactly do you think twitter.com has been using the api for? 

 


-Original Message-
From: twitter-development-talk@googlegroups.com 
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Alex Payne
Sent: Tuesday, September 15, 2009 5:16 PM
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff


The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> I emphatically second and support the idea of twitter.com having to use
> the API.
>
> We had similar quality problems at a place I formerly worked, and they
> were solved, completely, when such a policy was instituted.
>
> Yeah, it puts pressure on the API team and may inconvenience the UI
> team, or whatever you call them, but in the long run it will be worth
> it.
>
> Side effects that we saw were a simpler, cleaner, more consistent
> architecture for the whole system, and lower total costs to develop and
> maintain the system.
>
> Bite the bullet and do it now. The longer you wait, the more difficult
> and expensive it will be.
>
> Jim Renkel
>
> -Original Message-
> From: twitter-development-talk@googlegroups.com
> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> Haneda
> Sent: Tuesday, September 15, 2009 15:55
> To: twitter-development-talk@googlegroups.com
> Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
>
> Probably too late for this, but perhaps moving forward, it could be
> done...
> Twitter.com should move to using their own API.  The tools they use to
> power their own site should be the same tools we use and rely on.
>
> In all reality, this seems a simpler approach, rather than pushing out
> code for their stuff, and then essentially backporting that to an API,
> just work on making the API, and then integrate that into the
> twitter.com site.
>
> As far as I can tell, this would solve pretty much every problem the
> API has, as there can not be a case where twitter is down, but the API
> is up, or the API is down, and twitter is up.
>
> Twitter should be eating their own dog food :)
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>
>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> I emphatically second and support the idea of twitter.com having to use
> the API.
>
> We had similar quality problems at a place I formerly worked, and they
> were solved, completely, when such a policy was instituted.
>
> Yeah, it puts pressure on the API team and may inconvenience the UI
> team, or whatever you call them, but in the long run it will be worth
> it.
>
> Side effects that we saw were a simpler, cleaner, more consistent
> architecture for the whole system, and lower total costs to develop and
> maintain the system.
>
> Bite the bullet and do it now. The longer you wait, the more difficult
> and expensive it will be.
>
> Jim Renkel
>
> -Original Message-
> From: twitter-development-talk@googlegroups.com
> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> Haneda
> Sent: Tuesday, September 15, 2009 15:55
> To: twitter-development-talk@googlegroups.com
> Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
>
> Probably too late for this, but perhaps moving forward, it could be
> done...
> Twitter.com should move to using their own API.  The tools they use to
> power their own site should be the same tools we use and rely on.
>
> In all reality, this seems a simpler approach, rather than pushing out
> code for their stuff, and then essentially backporting that to an API,
> just work on making the API, and then integrate that into the
> twitter.com site.
>
> As far as I can tell, this would solve pretty much every problem the
> API has, as there can not be a case where twitter is down, but the API
> is up, or the API is down, and twitter is up.
>
> Twitter should be eating their own dog food :)
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>
>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Jim Renkel]

I emphatically second and support the idea of twitter.com having to use
the API.

We had similar quality problems at a place I formerly worked, and they
were solved, completely, when such a policy was instituted.

Yeah, it puts pressure on the API team and may inconvenience the UI
team, or whatever you call them, but in the long run it will be worth
it.

Side effects that we saw were a simpler, cleaner, more consistent
architecture for the whole system, and lower total costs to develop and
maintain the system.

Bite the bullet and do it now. The longer you wait, the more difficult
and expensive it will be. 

Jim Renkel

-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
Haneda
Sent: Tuesday, September 15, 2009 15:55
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff


Probably too late for this, but perhaps moving forward, it could be  
done...
Twitter.com should move to using their own API.  The tools they use to  
power their own site should be the same tools we use and rely on.

In all reality, this seems a simpler approach, rather than pushing out  
code for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.

As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.

Twitter should be eating their own dog food :)
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

Probably too late for this, but perhaps moving forward, it could be  
done...
Twitter.com should move to using their own API.  The tools they use to  
power their own site should be the same tools we use and rely on.


In all reality, this seems a simpler approach, rather than pushing out  
code for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.


As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.


Twitter should be eating their own dog food :)
--
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

Then maybe mark it in the docs as "highly experimental", this way,  
people do not build their business plans around something.  Make it  
clear, this feature could go away at any time.


On Sep 15, 2009, at 11:04 AM, Alex Payne wrote:


Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and we're doing our best to provide it.


--
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Paging STILL broken

[Jesse Stay]

Well done, Alex and team - thanks for getting this out so quick.  This will
solve many headaches!
Jesse

On Tue, Sep 15, 2009 at 2:43 PM, Alex Payne  wrote:

>
> Just wanted to follow up on this thread. We've pushed out a change and
> associated documentation that should allow for reliable, fast
> pagination through lists of denormalized IDs. Please kick the tires on
> the new "cursor"-based pagination:
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids
>
> On Mon, Sep 14, 2009 at 09:33, Ryan Sarver  wrote:
> >
> > Waldron,
> >
> > I wish I had an exact ETA for you, but unfortunately these types of
> > issues are never simple. As soon as we can identify exactly what is
> > causing the problem we should be able to know when it can be resolved.
> > I will update you with an ETA as soon as we can.
> >
> > Thanks, rs
> >
> > On Mon, Sep 14, 2009 at 5:23 AM, Waldron Faulkner
> >  wrote:
> >>
> >> That's awesome, Ryan, thanks. Can I get an ETA on a fix please? This
> >> is extremely important to my business, I need to know when I can begin
> >> selling. This bug has caused a delay, because I can't sell a broken
> >> product, even if it is Twitter's bug and not my own.
> >>
> >> So... ETA??
> >>
> >> Thanks!
> >>
> >> On Sep 13, 5:49 pm, Ryan Sarver  wrote:
> >>> Waldron,
> >>>
> >>> Thanks for the email. I am working with our team internally to track
> >>> down the issue and figure out how to resolve it. I will get back to
> >>> you with an update shortly, but know that we are listening and working
> >>> on this.
> >>>
> >>> Best, Ryan
> >>>
> >>> On Sun, Sep 13, 2009 at 8:55 AM, Waldron Faulkner
> >>>
> >>>  wrote:
> >>>
> >>> > PLEASE, can someone on the API team let us know when the paging
> bug(s)
> >>> > with followers/ids (and friends/ids) will be addressed? There have
> >>> > been problems with it for weeks, but now it's just downright broken.
> >>> > We can't get lists of followers for users with large numbers of
> >>> > followers. That's a basic, fundamental API feature that's just
> BROKEN.
> >>> > There's a reproduced, accepted, high priority bug against this issue
> >>> > in the "issues" area, starred by many, and we've had neither a fix,
> >>> > nor a comment as to whether it's even being addressed.
> >>>
> >>> > I need to know that I can expect problems with the platform's basic
> >>> > functionality to be resolved within a reasonable time-frame. This is
> >>> > killing my business development efforts. If Twitter wants people to
> >>> > build businesses on this platform, they HAVE to support it.
> >>>
> >>> > PLEASE guys, give us something. Don't make me throw away months of
> >>> > work and go focus on something unrelated to Twitter.
> >>
> >
>
>
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.
> http://twitter.com/al3x
>

[twitter-dev] Re: Paging STILL broken

[Alex Payne]

Just wanted to follow up on this thread. We've pushed out a change and
associated documentation that should allow for reliable, fast
pagination through lists of denormalized IDs. Please kick the tires on
the new "cursor"-based pagination:

http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids

On Mon, Sep 14, 2009 at 09:33, Ryan Sarver  wrote:
>
> Waldron,
>
> I wish I had an exact ETA for you, but unfortunately these types of
> issues are never simple. As soon as we can identify exactly what is
> causing the problem we should be able to know when it can be resolved.
> I will update you with an ETA as soon as we can.
>
> Thanks, rs
>
> On Mon, Sep 14, 2009 at 5:23 AM, Waldron Faulkner
>  wrote:
>>
>> That's awesome, Ryan, thanks. Can I get an ETA on a fix please? This
>> is extremely important to my business, I need to know when I can begin
>> selling. This bug has caused a delay, because I can't sell a broken
>> product, even if it is Twitter's bug and not my own.
>>
>> So... ETA??
>>
>> Thanks!
>>
>> On Sep 13, 5:49 pm, Ryan Sarver  wrote:
>>> Waldron,
>>>
>>> Thanks for the email. I am working with our team internally to track
>>> down the issue and figure out how to resolve it. I will get back to
>>> you with an update shortly, but know that we are listening and working
>>> on this.
>>>
>>> Best, Ryan
>>>
>>> On Sun, Sep 13, 2009 at 8:55 AM, Waldron Faulkner
>>>
>>>  wrote:
>>>
>>> > PLEASE, can someone on the API team let us know when the paging bug(s)
>>> > with followers/ids (and friends/ids) will be addressed? There have
>>> > been problems with it for weeks, but now it's just downright broken.
>>> > We can't get lists of followers for users with large numbers of
>>> > followers. That's a basic, fundamental API feature that's just BROKEN.
>>> > There's a reproduced, accepted, high priority bug against this issue
>>> > in the "issues" area, starred by many, and we've had neither a fix,
>>> > nor a comment as to whether it's even being addressed.
>>>
>>> > I need to know that I can expect problems with the platform's basic
>>> > functionality to be resolved within a reasonable time-frame. This is
>>> > killing my business development efforts. If Twitter wants people to
>>> > build businesses on this platform, they HAVE to support it.
>>>
>>> > PLEASE guys, give us something. Don't make me throw away months of
>>> > work and go focus on something unrelated to Twitter.
>>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[PJB]

Please also stop willy-nilly changing the error codes and error
messages.  Since your error messages are so often inaccurate, some of
us have setup special rules to decipher what the errors actually are
-- when you change the text or code, our rules break.

For example, suspended users are/were getting rate limit warnings when
trying to authenticate as them.  Separately, a new "not authorized"
message appears for both failed authentication errors as well as
successfully authenticated users trying friends/ids on blocking
users.  Since the messages and codes are the same, it is hard to
distinguish between these error types to tell the user what is going
on.  There are about a half-dozen of these ambiguities and bad errors
that we've accounted for.  (Don't get me started on "200: OK" non-
errors.)

So, after much trial and error, we CAN figure out the actual
underlying problem based on the action and message you send us.  But
when you suddenly change the error code, or message, it throws our
rules into disarray.

(Of course, it would be nice if the actual error messages you sent
were themselves accurate, but for now we're just hoping you can
CONSISTENTLY send us the same inaccurate errors.)


On Sep 15, 12:29 pm, Alex Payne  wrote:
> We're planning on doing just that: communicating more, monitoring the
> API via a third-party service from a variety of locales, and providing
> better documentation. We've got more developer support hires lined up,
> and more.
>
> Thanks for the list of what you'd like to see, and thanks for bearing with us.
>
>
>
> On Tue, Sep 15, 2009 at 12:13, zippy_monster  wrote:
>
> > On Sep 15, 11:04 am, Alex Payne  wrote:
>
> >> Please understand that the denormalized lists are currently provided
> >> to developers on a best-effort basis. For the vast majority of Twitter
> >> applications, this data isn't necessary. A specialized class of
> >> applications need this data, and we're doing our best to provide it.
>
> > As a developer, implementation details are mainly a recreational
> > interest.  My primary concern is the end result (does it work? or
> > not?).  Excuses and apologies are nice, but not a substitute for more
> > explicit testing and communication.  So far I've run into two
> > disruptive changes:
>
> > - Today, for a brief period, API queries were returning twice the
> > number of responses they should have.  Instead of showing the proper 6
> > DMs, I was getting 12 back.  Oops.
>
> > - Previously, the way POST + OAuth requests were being handled
> > changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> > was sending GET arguments with every request (even POST).  For a while
> > this worked, but in the past few weeks this broke with no warning.
> > Yeah, that was sloppy client-side code, but the documentation was
> > silent on this, and certainly the error message (invalid/re-used
> > nonce) was not terribly helpful as a proper nonce was being generated
> > each time.
>
> > Additionally, Internet rumblings about how OAuth was handled lend
> > credence to the idea that the API just isn't terribly stable... both
> > from the idea that you're pushing people to use what is officially
> > considered an experimental API, and that it's being treated as an
> > experimental API (OAuth specific outages for instance).
>
> > Or, the current pagination problems.  The threads I see here seem to
> > all be started by API consumers.  What's missing from the picture is
> > an announcement from Twitter that some feature is broken.  That smacks
> > of really poor (well, non-existent) communication.
>
> > So, yeah, after spending time tracking down the above problems, and
> > reading general internet rumblings, my gut feeling is that the Twitter
> > API simply isn't terribly stable.  Specifically, I wonder how serious
> > Twitter is about testing things in a non-production environment.  If I
> > had to propose a solution, it would be to keep a more explicit list
> > (blog, regular group postings, whatever) of what changes... even if
> > you think it's insignificant.  When something breaks, no matter how
> > small, a formal announcement would be great.  If such a thing exists,
> > I sure don't know about it.
>
> > The API blog hasn't been updated since July.  The third hit on Google
> > for "twitter api" is a post to this group begging for documentation.
> > The API changelog is out there, but it too seems like it's not
> > consistently updated.
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

We're planning on doing just that: communicating more, monitoring the
API via a third-party service from a variety of locales, and providing
better documentation. We've got more developer support hires lined up,
and more.

Thanks for the list of what you'd like to see, and thanks for bearing with us.

On Tue, Sep 15, 2009 at 12:13, zippy_monster  wrote:
>
> On Sep 15, 11:04 am, Alex Payne  wrote:
>
>> Please understand that the denormalized lists are currently provided
>> to developers on a best-effort basis. For the vast majority of Twitter
>> applications, this data isn't necessary. A specialized class of
>> applications need this data, and we're doing our best to provide it.
>
> As a developer, implementation details are mainly a recreational
> interest.  My primary concern is the end result (does it work? or
> not?).  Excuses and apologies are nice, but not a substitute for more
> explicit testing and communication.  So far I've run into two
> disruptive changes:
>
> - Today, for a brief period, API queries were returning twice the
> number of responses they should have.  Instead of showing the proper 6
> DMs, I was getting 12 back.  Oops.
>
> - Previously, the way POST + OAuth requests were being handled
> changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> was sending GET arguments with every request (even POST).  For a while
> this worked, but in the past few weeks this broke with no warning.
> Yeah, that was sloppy client-side code, but the documentation was
> silent on this, and certainly the error message (invalid/re-used
> nonce) was not terribly helpful as a proper nonce was being generated
> each time.
>
> Additionally, Internet rumblings about how OAuth was handled lend
> credence to the idea that the API just isn't terribly stable... both
> from the idea that you're pushing people to use what is officially
> considered an experimental API, and that it's being treated as an
> experimental API (OAuth specific outages for instance).
>
> Or, the current pagination problems.  The threads I see here seem to
> all be started by API consumers.  What's missing from the picture is
> an announcement from Twitter that some feature is broken.  That smacks
> of really poor (well, non-existent) communication.
>
> So, yeah, after spending time tracking down the above problems, and
> reading general internet rumblings, my gut feeling is that the Twitter
> API simply isn't terribly stable.  Specifically, I wonder how serious
> Twitter is about testing things in a non-production environment.  If I
> had to propose a solution, it would be to keep a more explicit list
> (blog, regular group postings, whatever) of what changes... even if
> you think it's insignificant.  When something breaks, no matter how
> small, a formal announcement would be great.  If such a thing exists,
> I sure don't know about it.
>
> The API blog hasn't been updated since July.  The third hit on Google
> for "twitter api" is a post to this group begging for documentation.
> The API changelog is out there, but it too seems like it's not
> consistently updated.
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 15, 11:04 am, Alex Payne  wrote:

> Please understand that the denormalized lists are currently provided
> to developers on a best-effort basis. For the vast majority of Twitter
> applications, this data isn't necessary. A specialized class of
> applications need this data, and we're doing our best to provide it.

As a developer, implementation details are mainly a recreational
interest.  My primary concern is the end result (does it work? or
not?).  Excuses and apologies are nice, but not a substitute for more
explicit testing and communication.  So far I've run into two
disruptive changes:

- Today, for a brief period, API queries were returning twice the
number of responses they should have.  Instead of showing the proper 6
DMs, I was getting 12 back.  Oops.

- Previously, the way POST + OAuth requests were being handled
changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
was sending GET arguments with every request (even POST).  For a while
this worked, but in the past few weeks this broke with no warning.
Yeah, that was sloppy client-side code, but the documentation was
silent on this, and certainly the error message (invalid/re-used
nonce) was not terribly helpful as a proper nonce was being generated
each time.

Additionally, Internet rumblings about how OAuth was handled lend
credence to the idea that the API just isn't terribly stable... both
from the idea that you're pushing people to use what is officially
considered an experimental API, and that it's being treated as an
experimental API (OAuth specific outages for instance).

Or, the current pagination problems.  The threads I see here seem to
all be started by API consumers.  What's missing from the picture is
an announcement from Twitter that some feature is broken.  That smacks
of really poor (well, non-existent) communication.

So, yeah, after spending time tracking down the above problems, and
reading general internet rumblings, my gut feeling is that the Twitter
API simply isn't terribly stable.  Specifically, I wonder how serious
Twitter is about testing things in a non-production environment.  If I
had to propose a solution, it would be to keep a more explicit list
(blog, regular group postings, whatever) of what changes... even if
you think it's insignificant.  When something breaks, no matter how
small, a formal announcement would be great.  If such a thing exists,
I sure don't know about it.

The API blog hasn't been updated since July.  The third hit on Google
for "twitter api" is a post to this group begging for documentation.
The API changelog is out there, but it too seems like it's not
consistently updated.

[twitter-dev] Follow or Login from Twitter Widget returns 'This Method Requires a GET'

[D Simone]

You guys had a bug acknowledgement back in August (13-15) but you've
removed it.  The widget still malfunctions.  I just downloaded it.
Will you be fixing it?  Suggest you remove the widget entirely if
not.  It's frustrating for developers to download software that
doesn't work.

http://74.125.95.132/search?q=cache:f2DO358g1UkJ:help.twitter.com/forums/31935/entries/41003.mobile+Follow+or+Login+from+Twitter+Widget+returns+%27This+Method+Requires+a+GET%27&hl=en&client=firefox-a&gl=ca&strip=0

Cheers,
D

[twitter-dev] Re: Default profile pics

[Scott Haneda]

I have not looked at this so this is mostly curiosity.

Why use md5 on a moving target? Who knows when someone may resave an  
image to compress it more.


I bet 1% compression savings translates to thousands of dollars over  
short time.


Isn't the path relatively static?

/images/default...

Maybe you can use the file path?

Do user profile images mantain the same trailing path as the default  
image?


Maybe then a 2x daily script that uses curl with regex support to find  
if any images up to a point 404. Looks like you have 5-6 known cases.


If you hit a 404 alert yourself, investigate, and make adjustments.

It sounds to me like those images are in control of designers not  
developers so I would consider those images hostile at all times.


I agree, has_updated_profile_image would be good for the API. As it is  
now, someone could upload a profile pic of the default, and it would  
appear as not being updated, when in fact it has.

--
Scott
Iphone says hello.

On Sep 15, 2009, at 4:38 AM, timwhitlock  
 wrote:




I notice today that Twitter has created a new default profile pic;
e.g:
http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png

Great. That's broken some of my algorithms on Twitblock.org.
(identifying re-used images)
I can fix that. I'll just add the new MD5 to my app config.

But, wait. Did I spot some different colours?
Yes, that example is only one; e.g.2:
http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png

a. Can Twitter tell use how many there are of these?
b. How about a user object property "profile_image_default" (true|
false) ?
c. How about Twitter start notifying the developer community of
changes?

[twitter-dev] Re: Comments for the group and Twitter staff

[Waldron Faulkner]

OK Alex, thanks for that insight. I'm trying hard to be patient, but I
hope you can understand that this issue is strangling my new business.

Also, I don't see anything in the documentation which differentiates
these social graph calls from those rising above support on a "best-
effort basis". I'm not trying to be argumentative, but it would help
me tremendously with prioritization of ongoing development if I knew
which other API calls won't receive priority support if they should
suddenly fail. If there is some internal prioritization, I think the
community needs to know what it is. I know I do!

Thanks,

- Waldron

On Sep 15, 2:04 pm, Alex Payne  wrote:
> Waldron,
>
> We're looking into this issue, but it requires a great deal of
> coordination with the folks who work on our back-end infrastructure.
> When you ask for a list of denormalized IDs, that request spends very
> little time in "API code", and most of its time talking to a back-end
> system that my team has no control over. We're working with the folks
> in charge of that on reliability and better ways for developers to
> access that data.
>
> Please understand that the denormalized lists are currently provided
> to developers on a best-effort basis. For the vast majority of Twitter
> applications, this data isn't necessary. A specialized class of
> applications need this data, and we're doing our best to provide it.
>
> On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
>
>
>
>  wrote:
>
> > Ryan, please look no further than existing, accepted issues in the
> > issues list for examples as to how this platform is not yet ready. One
> > of your primary API calls, followers/ids (and friends/ids) is broken,
> > and has been for more than a week now. Since paging is not working,
> > and un-paged requests on accounts with many followers yields fail
> > whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
> > it doesn't feel like it's getting any kind of response.
>
> > As I have said repeatedly in this forum and in the issues list, this
> > has frozen business development for my fledgling business, which I
> > have trusted to the Twitter API. I can't show a broken product. At
> > some point, you will put this little dream of mine out of business.
> > I'm up late working on my project, which will ultimately add value to
> > Twitter's business. I hope your team isn't leaving me high and dry.
> > Please tell me I don't have to go do a Facebook app instead. Please
> > tell me that someone was working on this over the weekend.
>
> > I'd love to have some solid, no-nonsense response to this, with hard
> > dates. So far we've had well-meaning but empty words.
>
> > Thanks,
>
> > - Waldron Faulkner
> > Founder, GraphEdge LLC.
> >http://graphedge.com
>
> > On Sep 15, 2:59 am, Ryan Sarver  wrote:
> >> WyoKnott,
>
> >> Thanks for your email. We really appreciate the candid feedback and
> >> definitely is not something we want to see happening. I would like to
> >> hear more about what you mean by "not stable enough" and what specific
> >> issues we can work on that would get you to consider Twitter a
> >> platform worthy of building your business on.
>
> >> I look forward to your feedback.
>
> >> Best, Ryan
>
> >> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
> >> wrote:
>
> >> > A few months ago I was introduced to the Twitter API by a prospective
> >> > client who wanted a custom application. I took the time to learn the
> >> > API and wrote a quick and dirty standalone windows app. The project
> >> > fell through (the client could not get financing) but I have continued
> >> > to be a twitter user and have subscribed to this group email. I
> >> > stopped development on the project because the API does not yet seem
> >> > stable enough for me to try to produce a marketable product on my own
> >> > while at the same time chasing an API around. Is my opinion way off
> >> > the mark or are some of the other developers out there feeling the
> >> > same way.
>
> >> > I am considering restarting development on the project if the Twitter
> >> > API is likely to get more stable in the near future.
>
> >> > Thanks for tolerating my ravings
>
> >> > WyoKnott
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

Waldron,

We're looking into this issue, but it requires a great deal of
coordination with the folks who work on our back-end infrastructure.
When you ask for a list of denormalized IDs, that request spends very
little time in "API code", and most of its time talking to a back-end
system that my team has no control over. We're working with the folks
in charge of that on reliability and better ways for developers to
access that data.

Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and we're doing our best to provide it.

On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
 wrote:
>
> Ryan, please look no further than existing, accepted issues in the
> issues list for examples as to how this platform is not yet ready. One
> of your primary API calls, followers/ids (and friends/ids) is broken,
> and has been for more than a week now. Since paging is not working,
> and un-paged requests on accounts with many followers yields fail
> whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
> it doesn't feel like it's getting any kind of response.
>
> As I have said repeatedly in this forum and in the issues list, this
> has frozen business development for my fledgling business, which I
> have trusted to the Twitter API. I can't show a broken product. At
> some point, you will put this little dream of mine out of business.
> I'm up late working on my project, which will ultimately add value to
> Twitter's business. I hope your team isn't leaving me high and dry.
> Please tell me I don't have to go do a Facebook app instead. Please
> tell me that someone was working on this over the weekend.
>
> I'd love to have some solid, no-nonsense response to this, with hard
> dates. So far we've had well-meaning but empty words.
>
> Thanks,
>
> - Waldron Faulkner
> Founder, GraphEdge LLC.
> http://graphedge.com
>
> On Sep 15, 2:59 am, Ryan Sarver  wrote:
>> WyoKnott,
>>
>> Thanks for your email. We really appreciate the candid feedback and
>> definitely is not something we want to see happening. I would like to
>> hear more about what you mean by "not stable enough" and what specific
>> issues we can work on that would get you to consider Twitter a
>> platform worthy of building your business on.
>>
>> I look forward to your feedback.
>>
>> Best, Ryan
>>
>> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
>> wrote:
>>
>> > A few months ago I was introduced to the Twitter API by a prospective
>> > client who wanted a custom application. I took the time to learn the
>> > API and wrote a quick and dirty standalone windows app. The project
>> > fell through (the client could not get financing) but I have continued
>> > to be a twitter user and have subscribed to this group email. I
>> > stopped development on the project because the API does not yet seem
>> > stable enough for me to try to produce a marketable product on my own
>> > while at the same time chasing an API around. Is my opinion way off
>> > the mark or are some of the other developers out there feeling the
>> > same way.
>>
>> > I am considering restarting development on the project if the Twitter
>> > API is likely to get more stable in the near future.
>>
>> > Thanks for tolerating my ravings
>>
>> > WyoKnott
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Default profile pics

[Alex Payne]

Tim,

We specify full URLs to images so that developers don't have to supply
custom code to pull in profile images and background images. It sounds
like you have a pretty unusual use case for our profile images.

For what it's worth, I think we deployed six variations of those
images, but our front end team may deploy more at any time. Similarly,
they may change up the default profile colors and such. That's out of
the control of our team.

On Tue, Sep 15, 2009 at 04:38, timwhitlock
 wrote:
>
> I notice today that Twitter has created a new default profile pic;
> e.g:
> http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png
>
> Great. That's broken some of my algorithms on Twitblock.org.
> (identifying re-used images)
> I can fix that. I'll just add the new MD5 to my app config.
>
> But, wait. Did I spot some different colours?
> Yes, that example is only one; e.g.2:
> http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png
>
> a. Can Twitter tell use how many there are of these?
> b. How about a user object property "profile_image_default" (true|
> false) ?
> c. How about Twitter start notifying the developer community of
> changes?
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Returned to show action

[peter_tellgren]

Dear all, I am struggling with a very annoying problem at the moment
and come here in hope that you are able to help me.
my dev env is: apache/passenger/rails2.2.2/mysql/twitter-gem
(junemakers)

I have a controller called social that have the following actions:
index, create, finalize, destroy

the create action redirects my user to twitter.com as follows
def create
  oauth.set_callback_url('http://example.com/user/social/finalize/')
  session['rtoken']  = oauth.request_token.token
  session['rsecret'] = oauth.request_token.secret
  redirect_to oauth.request_token.authorize_url
end

when done this aught to bring me back to my finalize action but
instead my return call is as follows
Completed in 522ms (DB: 8) | 302 Found [http://example.com/user/
social/]
Processing SocialController#show (for 127.0.0.1 at 2009-09-15
17:29:19) [GET]
Parameters: {"action"=>"show", "id"=>"finalize",
"controller"=>"social",  "oauth_token"=>"N...8",
"oauth_verifier"=>"E..M"}

I can't for my life understand why it insists in rendering the show
action instead of executing the finalize action.

in my routes I have defined the following:
  map.resources :social, :member => { :finalize
=> :get }, :path_prefix => '/user'

Any kind of assistance would be greatly appreciated.

[twitter-dev] Re: Twitter for Motorcycle Riders

[mycroftt]

Looks like a good opportunity for a niche twitter app. If I trusted the API a bit more I'd help you develop it. I'm sure there are several programmers thinking about it right now, once you exposed the idea.
 

 Original Message Subject: [twitter-dev] Twitter for Motorcycle RidersFrom: "Thomas Hirschmann" Date: Tue, September 15, 2009 5:31 amTo: 



Hi there.
 
I am a motorcycle freak and would like to know if there is a possibility to use twitter to improve motorcycle riding, e.g.
 
Ø  finding out where the police is hiding to catch you for speeding
Ø  finding out about the best motorcycle streets / routes
Ø  finding out about the best overnight stays / hotels for riders
Ø  finding out about the best food on the road
Ø  finding out about other riders in my area
 
Could I help realize this with you?
 
Best regards,
 
Thomas
 
 
Thomas Hirschmann
Clemensstr. 81, 80796 München
 
Tel.:  +49 (0)89 - 201 857 42
Fax:  +49 (0)3212 - 10 46 952
Mobil:  +49 (0)151-284 16 195
 
E-Mail:  thomas.hirschm...@gmail.com
Web: www.thomashirschmann.de
Skype:  thomas_hirschmann
 

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[Nigel Cannings]

You'll know, trust me, having just got done for posting too many 
hashtags We've been automatically tagging users' feeds, and posting 
the resulting hashtags centrally on @linkkytags - Until the middle of 
last night!


So, unless begging works (which it hasn't so far), we'll be pursuing 
plan B which is to go all OAuth, and post the tags periodically to 
users' feeds so they're spread around all the different feeds.  Not 
actually as socially useful, and it means we'll have to post the 
aggregated hashtags off-Twitter, but better than nothing...


Nigel
@ncannings
http://tweet.linkky.com
http://tweet.linkky.com/yourtwitteridhere

Joseph Cheek wrote:

out of curiosity, how can you tell if your account is flagged as spammy,
and what can you do about it?

Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom


John Kalucki wrote:

This is taken from the Twitter Rules, not the TOS, so this isn't
expressly against the TOS. Rather, this is one guideline of many that
Twitter may use to determine if an account is spammy. If job postings
are otherwise good and useful, I wouldn't fret too much. But, I'd also
expect that you just might, on rare occasion, may have to deal with
getting your accounts unflagged as spammy.

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



On Sep 15, 7:58 am, HardipSingh  wrote:
  

I am curious how the following rule impact those that are auto-
tweeting job links to #jobs and the other twitter job boards.

* If your updates consist mainly of links, and not personal updates;

Does this mean that we are in violation of this rule if I have an
account that is primarily responsible for tweeting job links?

Thanks in advance for your time.

~ H

[twitter-dev] Re: Default profile pics

[Jesse Stay]

I don't think it sounded hostile, and it sounded to me like he was proposing
it be part of the API, which I agree.  That would be pretty useful
information, especially in a constantly changing environment.

Jesse

On Tue, Sep 15, 2009 at 9:52 AM, Adam Cloud  wrote:

> This is a pretty hostile worded email for someone who is asking for help
> for a problem that isn't necessarily directly related to the API.
>
> Just saying...
>

[twitter-dev] Re: Default profile pics

[Jim Renkel]

Factoid, FWIW: so far, I've found 7:

http://s.twimg.com/a/1252980779/images/default_profile_x_normal.png

where 0<=x<=6.

Jim Renkel

-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of
timwhitlock
Sent: Tuesday, September 15, 2009 06:39
To: Twitter Development Talk
Subject: [twitter-dev] Default profile pics


I notice today that Twitter has created a new default profile pic;
e.g:
http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png

Great. That's broken some of my algorithms on Twitblock.org.
(identifying re-used images)
I can fix that. I'll just add the new MD5 to my app config.

But, wait. Did I spot some different colours?
Yes, that example is only one; e.g.2:
http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png

a. Can Twitter tell use how many there are of these?
b. How about a user object property "profile_image_default" (true|
false) ?
c. How about Twitter start notifying the developer community of
changes?

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[Joseph Cheek]

ok.  i have an account that never shows up in search results or in
track.xml.  i thought that might be it, but i guess not.

Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom



John Kalucki wrote:
> The account will be suspended. It won't work, and it won't be
> visible.
>
> You can file a support ticket and contemplate your apparent or actual
> transgressions as you wait for them to sort out the account's fate. At
> first glance this may not seem fair, but the vast majority of accounts
> that are suspended are indeed spammy, and it takes a while to weed
> through the piles of disinformation to find the proportionally very
> few false positives.
>
> -John
>
>
> On Sep 15, 9:20 am, Joseph Cheek  wrote:
>   
>> out of curiosity, how can you tell if your account is flagged as spammy,
>> and what can you do about it?
>>
>> Joseph Cheek
>> jos...@cheek.com,www.cheek.com
>> twitter:http://twitter.com/cheekdotcom
>>
>> John Kalucki wrote:
>> 
>>> This is taken from the Twitter Rules, not the TOS, so this isn't
>>> expressly against the TOS. Rather, this is one guideline of many that
>>> Twitter may use to determine if an account is spammy. If job postings
>>> are otherwise good and useful, I wouldn't fret too much. But, I'd also
>>> expect that you just might, on rare occasion, may have to deal with
>>> getting your accounts unflagged as spammy.
>>>   
>>> -John Kalucki
>>> http://twitter.com/jkalucki
>>> Services, Twitter Inc.
>>>   
>>> On Sep 15, 7:58 am, HardipSingh  wrote:
>>>   
 I am curious how the following rule impact those that are auto-
 tweeting job links to #jobs and the other twitter job boards.
 
 * If your updates consist mainly of links, and not personal updates;
 
 Does this mean that we are in violation of this rule if I have an
 account that is primarily responsible for tweeting job links?
 
 Thanks in advance for your time.
 
 ~ H
 

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[HardipSingh]

Thanks for the prompt response John.  This info helps a lot.  Looks
like we should be OK then, but we will keep an eye out to make sure
none of our flagged as spammy.

~ H

On Sep 15, 12:15 pm, John Kalucki  wrote:
> This is taken from the Twitter Rules, not the TOS, so this isn't
> expressly against the TOS. Rather, this is one guideline of many that
> Twitter may use to determine if an account is spammy. If job postings
> are otherwise good and useful, I wouldn't fret too much. But, I'd also
> expect that you just might, on rare occasion, may have to deal with
> getting your accounts unflagged as spammy.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Sep 15, 7:58 am, HardipSingh  wrote:
>
> > I am curious how the following rule impact those that are auto-
> > tweeting job links to #jobs and the other twitter job boards.
>
> > * If your updates consist mainly of links, and not personal updates;
>
> > Does this mean that we are in violation of this rule if I have an
> > account that is primarily responsible for tweeting job links?
>
> > Thanks in advance for your time.
>
> > ~ H

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[John Kalucki]

The account will be suspended. It won't work, and it won't be
visible.

You can file a support ticket and contemplate your apparent or actual
transgressions as you wait for them to sort out the account's fate. At
first glance this may not seem fair, but the vast majority of accounts
that are suspended are indeed spammy, and it takes a while to weed
through the piles of disinformation to find the proportionally very
few false positives.

-John


On Sep 15, 9:20 am, Joseph Cheek  wrote:
> out of curiosity, how can you tell if your account is flagged as spammy,
> and what can you do about it?
>
> Joseph Cheek
> jos...@cheek.com,www.cheek.com
> twitter:http://twitter.com/cheekdotcom
>
> John Kalucki wrote:
> > This is taken from the Twitter Rules, not the TOS, so this isn't
> > expressly against the TOS. Rather, this is one guideline of many that
> > Twitter may use to determine if an account is spammy. If job postings
> > are otherwise good and useful, I wouldn't fret too much. But, I'd also
> > expect that you just might, on rare occasion, may have to deal with
> > getting your accounts unflagged as spammy.
>
> > -John Kalucki
> >http://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Sep 15, 7:58 am, HardipSingh  wrote:
>
> >> I am curious how the following rule impact those that are auto-
> >> tweeting job links to #jobs and the other twitter job boards.
>
> >> * If your updates consist mainly of links, and not personal updates;
>
> >> Does this mean that we are in violation of this rule if I have an
> >> account that is primarily responsible for tweeting job links?
>
> >> Thanks in advance for your time.
>
> >> ~ H

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[Joseph Cheek]

out of curiosity, how can you tell if your account is flagged as spammy,
and what can you do about it?

Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom


John Kalucki wrote:
> This is taken from the Twitter Rules, not the TOS, so this isn't
> expressly against the TOS. Rather, this is one guideline of many that
> Twitter may use to determine if an account is spammy. If job postings
> are otherwise good and useful, I wouldn't fret too much. But, I'd also
> expect that you just might, on rare occasion, may have to deal with
> getting your accounts unflagged as spammy.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Services, Twitter Inc.
>
>
>
> On Sep 15, 7:58 am, HardipSingh  wrote:
>   
>> I am curious how the following rule impact those that are auto-
>> tweeting job links to #jobs and the other twitter job boards.
>>
>> * If your updates consist mainly of links, and not personal updates;
>>
>> Does this mean that we are in violation of this rule if I have an
>> account that is primarily responsible for tweeting job links?
>>
>> Thanks in advance for your time.
>>
>> ~ H
>> 

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[John Kalucki]

This is taken from the Twitter Rules, not the TOS, so this isn't
expressly against the TOS. Rather, this is one guideline of many that
Twitter may use to determine if an account is spammy. If job postings
are otherwise good and useful, I wouldn't fret too much. But, I'd also
expect that you just might, on rare occasion, may have to deal with
getting your accounts unflagged as spammy.

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



On Sep 15, 7:58 am, HardipSingh  wrote:
> I am curious how the following rule impact those that are auto-
> tweeting job links to #jobs and the other twitter job boards.
>
> * If your updates consist mainly of links, and not personal updates;
>
> Does this mean that we are in violation of this rule if I have an
> account that is primarily responsible for tweeting job links?
>
> Thanks in advance for your time.
>
> ~ H

[twitter-dev] Re: Default profile pics

[John Kalucki]

Tim,

Twitter deploys dozens of code branches each week, most of which
probably contains at least a few user visible changes. The changelog
is difficult enough to follow internally. Externally, it would be
hopeless. Notifying on each and every change isn't a tractable
problem.

Although there is still room for improvement, the Platform team is
committed to notifying on functionality change in the API.

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



On Sep 15, 4:38 am, timwhitlock 
wrote:
> I notice today that Twitter has created a new default profile pic;
> e.g:http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png
>
> Great. That's broken some of my algorithms on Twitblock.org.
> (identifying re-used images)
> I can fix that. I'll just add the new MD5 to my app config.
>
> But, wait. Did I spot some different colours?
> Yes, that example is only one; 
> e.g.2:http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png
>
> a. Can Twitter tell use how many there are of these?
> b. How about a user object property "profile_image_default" (true|
> false) ?
> c. How about Twitter start notifying the developer community of
> changes?

[twitter-dev] Re: Default profile pics

[Adam Cloud]

This is a pretty hostile worded email for someone who is asking for help for
a problem that isn't necessarily directly related to the API.

Just saying...

[twitter-dev] re: Changes to Twitter TOS/Rules.

[HardipSingh]

I am curious how the following rule impact those that are auto-
tweeting job links to #jobs and the other twitter job boards.

* If your updates consist mainly of links, and not personal updates;


Does this mean that we are in violation of this rule if I have an
account that is primarily responsible for tweeting job links?

Thanks in advance for your time.

~ H

[twitter-dev] Twitter for Motorcycle Riders

[Thomas Hirschmann]

Hi there.

 

I am a motorcycle freak and would like to know if there is a possibility to
use twitter to improve motorcycle riding, e.g.

 

Ø  finding out where the police is hiding to catch you for speeding

Ø  finding out about the best motorcycle streets / routes

Ø  finding out about the best overnight stays / hotels for riders

Ø  finding out about the best food on the road

Ø  finding out about other riders in my area

 

Could I help realize this with you?

 

Best regards,

 

Thomas

 

 

Thomas Hirschmann

 
 Clemensstr. 81, 80796
München

 

Tel.:  +49 (0)89 - 201 857 42

Fax:  +49 (0)3212 - 10 46 952

Mobil:  +49 (0)151-284 16 195

 

E-Mail:  thomas.hirschm...@gmail.com

Web: www.thomashirschmann.de

Skype:  thomas_hirschmann  

 

[twitter-dev] Default profile pics

[timwhitlock]

I notice today that Twitter has created a new default profile pic;
e.g:
http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png

Great. That's broken some of my algorithms on Twitblock.org.
(identifying re-used images)
I can fix that. I'll just add the new MD5 to my app config.

But, wait. Did I spot some different colours?
Yes, that example is only one; e.g.2:
http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png

a. Can Twitter tell use how many there are of these?
b. How about a user object property "profile_image_default" (true|
false) ?
c. How about Twitter start notifying the developer community of
changes?

[twitter-dev] Re: Comments for the group and Twitter staff

[mycroftt]

I am only one person with too many irons in the fire. During the month or so that I spent actively working on the Twitter API project I had to go back and change parts my code more than once, not because of my errors (plenty of those but not the subject of this communication), but because of changes or proposed changes in the API. I would love to be in a position where I could focus exclusvely on this one project but I am not. As well as an ongoing job search I have a couple other projects showing promise. I cannot justify more time on Twitter when I see no point where the project graduates from in-development to live and in maintenance mode.
 

 Original Message Subject: [twitter-dev] Re: Comments for the group and Twitter staffFrom: Ryan Sarver Date: Mon, September 14, 2009 11:59 pmTo: twitter-development-talk@googlegroups.comWyoKnott,Thanks for your email. We really appreciate the candid feedback anddefinitely is not something we want to see happening. I would like tohear more about what you mean by "not stable enough" and what specificissues we can work on that would get you to consider Twitter aplatform worthy of building your business on.I look forward to your feedback.Best, Ryan

[twitter-dev] Re: Source parameter only available through oauth - misses a use case

[twittme_mobi]

Ok, but againplease make OAuth pages at twitter mobile friendly so
that the mobile web sites can use it!

On Sep 15, 11:28 am, Duane Roelands  wrote:
> It's an incentive to move to OAuth.
>
> Twitter has made their intentions clear about Basic Auth: They want it
> to go away.  By restricting the "source" parameter to OAuth requests,
> they give developers an incentive to move forward.
>
> On Sep 15, 4:20 am, Emrah  wrote:
>
> > I totally agree... Ivo, I got the same answers for a pretty similar
> > question some months ago...
> > I do not see the link between the source parameter and how the
> > authentication is made...
>
> > Cheers!
>
> > Ivo wrote:
> > > Hi,
>
> > > short answer: oauth is for delegated authentication; I'm using direct
> > > authentication of my own account. Both are valid use cases, so in my
> > > opinion the source parameter should continue to work for the second
> > > use case (I can't find a good reason to only support it for delegated
> > > authentication)
>
> > > Besides; all the examples you mention are for delegated
> > > authentication; it would be weird to have a headless system that is
> > > working as a service implement an oauth scheme.
>
> > > greetings,
> > > Ivo
>
> > > On Sep 14, 12:09 pm, Andrew Badera  wrote:
>
> > >> With all the freely available examples, and all the freely available
> > >> documentation and support available through oauth.net, what's stopping
> > >> you from cranking out an OAuth client implementation in <2 hours?
>
> > >> OAuth helps prevent, or at least make obvious for the time being,
> > >> spammers. HTTP Basic Auth has no value here.
>
> > >> ∞ Andy Badera
> > >> ∞ +1 518-641-1280
> > >> ∞ This email is: [ ] bloggable [x] ask first [ ] private
> > >> ∞ Google me:http://www.google.com/search?q=andrew%20badera
>
> > >> On Mon, Sep 14, 2009 at 1:48 AM, Ivo  wrote:
>
> > >>> Hi,
>
> > >>> the developer wiki mentions that the source parameter is no longer
> > >>> recommended, because using oauth, twitter can already know the source
> > >>> of messages.
>
> > >>> However, there are a few use case scenario's that are limited if
> > >>> source is only available through oauth.
>
> > >>> Oauth is all about delegated authentication. It's about the user
> > >>> granting access to his resources to a service.
>
> > >>> There are services out there that do not use the user's credentials at
> > >>> all, but use their own account. E.g. I built flackr.net, and it logs
> > >>> in with its own @flackr account to follow its own timeline and
> > >>> aggregate news on a website. I don't need user's credentials at all
> > >>> for that. The Flackr backend is autonomous and runs on a server that
> > >>> has no web frontend, it just fetches data and processes it. It does
> > >>> send out tweets when it has aggregated something interesting.
>
> > >>> If I were to use oauth in this scenario I would have to build in full
> > >>> oauth support in my backend script, only to login once with my own
> > >>> account to grant myself access.  Since this is not about delegated
> > >>> access, I don't need oauth and can authenticate against twitter
> > >>> directly.
>
> > >>> This is a perfectly good use case scenario, and the source parameter
> > >>> would have to stay in order to support this use case scenario while
> > >>> still providing a different source.

[twitter-dev] Re: Source parameter only available through oauth - misses a use case

[Duane Roelands]

It's an incentive to move to OAuth.

Twitter has made their intentions clear about Basic Auth: They want it
to go away.  By restricting the "source" parameter to OAuth requests,
they give developers an incentive to move forward.


On Sep 15, 4:20 am, Emrah  wrote:
> I totally agree... Ivo, I got the same answers for a pretty similar
> question some months ago...
> I do not see the link between the source parameter and how the
> authentication is made...
>
> Cheers!
>
>
>
> Ivo wrote:
> > Hi,
>
> > short answer: oauth is for delegated authentication; I'm using direct
> > authentication of my own account. Both are valid use cases, so in my
> > opinion the source parameter should continue to work for the second
> > use case (I can't find a good reason to only support it for delegated
> > authentication)
>
> > Besides; all the examples you mention are for delegated
> > authentication; it would be weird to have a headless system that is
> > working as a service implement an oauth scheme.
>
> > greetings,
> > Ivo
>
> > On Sep 14, 12:09 pm, Andrew Badera  wrote:
>
> >> With all the freely available examples, and all the freely available
> >> documentation and support available through oauth.net, what's stopping
> >> you from cranking out an OAuth client implementation in <2 hours?
>
> >> OAuth helps prevent, or at least make obvious for the time being,
> >> spammers. HTTP Basic Auth has no value here.
>
> >> ∞ Andy Badera
> >> ∞ +1 518-641-1280
> >> ∞ This email is: [ ] bloggable [x] ask first [ ] private
> >> ∞ Google me:http://www.google.com/search?q=andrew%20badera
>
> >> On Mon, Sep 14, 2009 at 1:48 AM, Ivo  wrote:
>
> >>> Hi,
>
> >>> the developer wiki mentions that the source parameter is no longer
> >>> recommended, because using oauth, twitter can already know the source
> >>> of messages.
>
> >>> However, there are a few use case scenario's that are limited if
> >>> source is only available through oauth.
>
> >>> Oauth is all about delegated authentication. It's about the user
> >>> granting access to his resources to a service.
>
> >>> There are services out there that do not use the user's credentials at
> >>> all, but use their own account. E.g. I built flackr.net, and it logs
> >>> in with its own @flackr account to follow its own timeline and
> >>> aggregate news on a website. I don't need user's credentials at all
> >>> for that. The Flackr backend is autonomous and runs on a server that
> >>> has no web frontend, it just fetches data and processes it. It does
> >>> send out tweets when it has aggregated something interesting.
>
> >>> If I were to use oauth in this scenario I would have to build in full
> >>> oauth support in my backend script, only to login once with my own
> >>> account to grant myself access.  Since this is not about delegated
> >>> access, I don't need oauth and can authenticate against twitter
> >>> directly.
>
> >>> This is a perfectly good use case scenario, and the source parameter
> >>> would have to stay in order to support this use case scenario while
> >>> still providing a different source.

[twitter-dev] Re: Source parameter only available through oauth - misses a use case

[Emrah]

I totally agree... Ivo, I got the same answers for a pretty similar
question some months ago...
I do not see the link between the source parameter and how the
authentication is made...

Cheers!

Ivo wrote:
> Hi,
>
> short answer: oauth is for delegated authentication; I'm using direct
> authentication of my own account. Both are valid use cases, so in my
> opinion the source parameter should continue to work for the second
> use case (I can't find a good reason to only support it for delegated
> authentication)
>
> Besides; all the examples you mention are for delegated
> authentication; it would be weird to have a headless system that is
> working as a service implement an oauth scheme.
>
> greetings,
> Ivo
>
> On Sep 14, 12:09 pm, Andrew Badera  wrote:
>   
>> With all the freely available examples, and all the freely available
>> documentation and support available through oauth.net, what's stopping
>> you from cranking out an OAuth client implementation in <2 hours?
>>
>> OAuth helps prevent, or at least make obvious for the time being,
>> spammers. HTTP Basic Auth has no value here.
>>
>> ∞ Andy Badera
>> ∞ +1 518-641-1280
>> ∞ This email is: [ ] bloggable [x] ask first [ ] private
>> ∞ Google me:http://www.google.com/search?q=andrew%20badera
>>
>> On Mon, Sep 14, 2009 at 1:48 AM, Ivo  wrote:
>>
>> 
>>> Hi,
>>>   
>>> the developer wiki mentions that the source parameter is no longer
>>> recommended, because using oauth, twitter can already know the source
>>> of messages.
>>>   
>>> However, there are a few use case scenario's that are limited if
>>> source is only available through oauth.
>>>   
>>> Oauth is all about delegated authentication. It's about the user
>>> granting access to his resources to a service.
>>>   
>>> There are services out there that do not use the user's credentials at
>>> all, but use their own account. E.g. I built flackr.net, and it logs
>>> in with its own @flackr account to follow its own timeline and
>>> aggregate news on a website. I don't need user's credentials at all
>>> for that. The Flackr backend is autonomous and runs on a server that
>>> has no web frontend, it just fetches data and processes it. It does
>>> send out tweets when it has aggregated something interesting.
>>>   
>>> If I were to use oauth in this scenario I would have to build in full
>>> oauth support in my backend script, only to login once with my own
>>> account to grant myself access.  Since this is not about delegated
>>> access, I don't need oauth and can authenticate against twitter
>>> directly.
>>>   
>>> This is a perfectly good use case scenario, and the source parameter
>>> would have to stay in order to support this use case scenario while
>>> still providing a different source.
>>>   

[twitter-dev] Re: empty data + no error returned from friends/ids

[Waldron Faulkner]

Hello, Raffi,

This is not the non-json response issue. This is open, accepted, high
priority issue #1019. Be the hero that fixes this for us, it's
breaking my back. Ryan and Alex aren't helping me out, maybe you can
be THE MAN! Please fix this, PLEASE!


On Sep 14, 6:36 pm, Raffi Krikorian  wrote:
> > We are seeing random, intermittent empty result sets from friends/ids,
> > called without page or cursor arguments.  These empty results return
> > without error, and frequently "correct" themselves when tried again.
> > Is this a known issue?  What is the status of this issue?
>
> hi PJB.
>
> i don't know of this particular issue, unless it is the same issue as  
> the non json responses that have been reported:
>
> http://groups.google.com/group/twitter-development-talk/browse_thread...
>
> if so, we're actively working on it.  if you think you have a  
> different issue, if possible, could you send me a tcpdump of when that  
> error occurs?
>
> thanks!
>
> --
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi

[twitter-dev] Re: Comments for the group and Twitter staff

[Waldron Faulkner]

Ryan, please look no further than existing, accepted issues in the
issues list for examples as to how this platform is not yet ready. One
of your primary API calls, followers/ids (and friends/ids) is broken,
and has been for more than a week now. Since paging is not working,
and un-paged requests on accounts with many followers yields fail
whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
it doesn't feel like it's getting any kind of response.

As I have said repeatedly in this forum and in the issues list, this
has frozen business development for my fledgling business, which I
have trusted to the Twitter API. I can't show a broken product. At
some point, you will put this little dream of mine out of business.
I'm up late working on my project, which will ultimately add value to
Twitter's business. I hope your team isn't leaving me high and dry.
Please tell me I don't have to go do a Facebook app instead. Please
tell me that someone was working on this over the weekend.

I'd love to have some solid, no-nonsense response to this, with hard
dates. So far we've had well-meaning but empty words.

Thanks,

- Waldron Faulkner
Founder, GraphEdge LLC.
http://graphedge.com

On Sep 15, 2:59 am, Ryan Sarver  wrote:
> WyoKnott,
>
> Thanks for your email. We really appreciate the candid feedback and
> definitely is not something we want to see happening. I would like to
> hear more about what you mean by "not stable enough" and what specific
> issues we can work on that would get you to consider Twitter a
> platform worthy of building your business on.
>
> I look forward to your feedback.
>
> Best, Ryan
>
> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
> wrote:
>
> > A few months ago I was introduced to the Twitter API by a prospective
> > client who wanted a custom application. I took the time to learn the
> > API and wrote a quick and dirty standalone windows app. The project
> > fell through (the client could not get financing) but I have continued
> > to be a twitter user and have subscribed to this group email. I
> > stopped development on the project because the API does not yet seem
> > stable enough for me to try to produce a marketable product on my own
> > while at the same time chasing an API around. Is my opinion way off
> > the mark or are some of the other developers out there feeling the
> > same way.
>
> > I am considering restarting development on the project if the Twitter
> > API is likely to get more stable in the near future.
>
> > Thanks for tolerating my ravings
>
> > WyoKnott

[twitter-dev] Re: Comments for the group and Twitter staff

[Ryan Sarver]

WyoKnott,

Thanks for your email. We really appreciate the candid feedback and
definitely is not something we want to see happening. I would like to
hear more about what you mean by "not stable enough" and what specific
issues we can work on that would get you to consider Twitter a
platform worthy of building your business on.

I look forward to your feedback.

Best, Ryan

On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  wrote:
>
> A few months ago I was introduced to the Twitter API by a prospective
> client who wanted a custom application. I took the time to learn the
> API and wrote a quick and dirty standalone windows app. The project
> fell through (the client could not get financing) but I have continued
> to be a twitter user and have subscribed to this group email. I
> stopped development on the project because the API does not yet seem
> stable enough for me to try to produce a marketable product on my own
> while at the same time chasing an API around. Is my opinion way off
> the mark or are some of the other developers out there feeling the
> same way.
>
> I am considering restarting development on the project if the Twitter
> API is likely to get more stable in the near future.
>
> Thanks for tolerating my ravings
>
> WyoKnott
>