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