Hi John,

This seems like a rather strange policy. Is the cost of having one User
Streams connection not far lower than having a connection to Site
Streams? That's what Justin asked, just one connection.

Tom


On 9/16/10 6:22 AM, John Kalucki wrote:
> Our intention is that User Streams and Site Streams will, shortly, offer
> the same data and filtering options at a similar, if not identical, QoS.
> I'm sure some subtleties will creep in over time, as they always do, but
> this parity is our goal.
> 
> The major difference is that User Streams, given its higher per-user
> cost, is limited only to user-based applications that connect directly
> to the Twitter API. In this use case, we have no alternative but to
> service a connection from each user device. Site Streams, on the other
> hand, allows services, such as your website, to open many User Streams
> multiplexed over a smaller number of connections. This reduces per-user
> cost, and makes large scale integrations tractable. Several pretty large
> services have integrated with Site Streams in just a few days, so this
> multiplexing is unlikely to be an undue additional burden over a User
> Streams integration, and might even save a lot of work over time.
> 
> If you attempt to use User Streams from a service, we can trivially
> detect this situation, and we'll classify your usage as against the TOS.
> To put our current thinking as bluntly as possible: we intend to enforce
> the distinction between User Streams and Site Streams via revocation of
> access.
> 
> -John Kalucki
> http://twitter.com/jkalucki
> Twitter, Inc.
> 
> 
> 
> On Wed, Sep 15, 2010 at 12:24 PM, Justin <justin.carl...@gmail.com
> <mailto:justin.carl...@gmail.com>> wrote:
> 
>     I've successfully migrated one of my sites away from making search and
>     mention rest calls, switched over to the streaming API and I'm loving
>     it. I still need to move it to OAuth but now that I have that in test
>     I'm reading up on the User and Site streams and I have a question.
> 
>     It seems the User stream states that websites should not use it, and
>     should use the Site stream instead, but I don't consume or care about
>     my user's activity, my site is centered around the messages and
>     interactions with the application user not the users themselves.
> 
>     Right now I track and evaluate followers and other bits using the rest
>     calls but from what I see I could eliminate those rest calls and be
>     off them (possibly) all together if I could use the User stream to
>     accept information about new and broken friendships, favorites, dms,
>     etc.
> 
>     Is it acceptable to use the User stream in that manor since I would
>     only need it for the app user account not my site user's accounts? If
>     so, I can just maintain the two streams (filtered streaming api and
>     user stream) and eliminate or cut back my rest calls dramatically?
>     Please let me know so I can plan accordingly.
> 
>     --
>     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?hl=en
> 
> 
> -- 
> 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?hl=en

-- 
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?hl=en

Reply via email to