Ryan, you said in another post in this thread that statuses/user_timeline is
still allowed. I'm curious how that jives with your second sentence here, "It's
apps that render a user their timeline."

What will happen if an app falls into a gray area of being a client or
consumer client? Will we simply have our Oauth tokens revoked, or will there
be some sort of review process? Will their be a deadline for current
client-only apps to find a way to fit the new TOS?

-Craig


On 12 March 2011 19:47, Ryan Sarver <rsar...@twitter.com> wrote:

> Mike, a client is one that recreates the twitter experience, or in your
> words the "primary" experience. So I don't consider Instagram or Foursquare
> in that group. It's apps that render a user their timeline.
>
> Apps that post into Twitter are great and explicitly called out at the
> bottom of the email.
>
> Hope that helps clarify.
>
> Best, Ryan
> --
>  Ryan Sarver
> @rsarver <http://twitter.com/rsarver>
>
>
>
> On Fri, Mar 11, 2011 at 9:09 PM, Mike Champion <mike.champ...@gmail.com>wrote:
>
>> Thanks for the clarification Ryan. Two questions:
>>
>> 1) Do you have a clear definition of what counts as a Twitter client?
>> Is it any app/service that posts updates to Twitter, including apps
>> like twitterfeed and Instapaper? Or is it only those apps that are
>> "primarily" clients? I'm certainly familiar with the challenge of
>> classifying apps ;) but wanted to know who will be covered by the ToS
>> Section 1.5 and how you think about "clients" given Twitter's updated
>> stance.
>>
>> 2) In section 1.5.A of the ToS it says:
>>
>> "Your Client must use the Twitter API as the sole source for features
>> that are substantially similar to functionality offered by Twitter.
>> Some examples include trending topics, who to follow, and suggested
>> user lists."
>>
>> Is the "Who to follow" functionality available via API from Twitter
>> for clients that want to offer this? I wasn't aware that it been
>> released as API but may have missed it on dev.twitter.com.
>>
>> Thanks,
>>
>> -mike
>>
>> On Mar 11, 3:47 pm, Eric Mill <kproject...@gmail.com> wrote:
>> > "More specifically, developers ask us if they should build client apps
>> that
>> > mimic or reproduce the mainstream Twitter consumer client experience.
>>  The
>> > answer is no."
>> >
>> > "We need to ensure users can interact with Twitter the same way
>> everywhere."
>> >
>> > I'm not sure you can say these things and simultaneously try to say you
>> have
>> > a welcoming developer environment. All third party Twitter developers,
>> no
>> > matter what they make, are now walking on eggshells, constantly at risk
>> of
>> > offending Twitter's ideas of how users should interact with Twitter.
>> >
>> > You may feel you "need" this consistency, but you don't. You want it,
>> and
>> > are willing to make tradeoffs to get it. I just hope you realize how big
>> > those tradeoffs are, and how chilling it is for Twitter to decide that
>> only
>> > certain kinds of innovation on the Twitter API are welcome.
>> >
>> > -- Eric
>>
>> --
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker:
>> http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group:
>> http://groups.google.com/group/twitter-development-talk
>>
>
>  --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>

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

Reply via email to