I'm sorry, I laid out the difference between User Streams and Site Streams, but I forgot to bring it all back to the specific question at hand.
The critical difference isn't Desktop vs. Web Site-- that's the general case description. The key difference is that you must multiplex if you open more than a handful of connections. In this specific case, there's nothing to multiplex, so remaining on User Streams is OK, despite coming from a server. The usage is really as if a single user was monitoring an account. To answer Tom's question, currently a User Stream connection and a Site Stream connection with a single user have the same cost. Sorry for the incomplete answer. Does this make sense? -John On Wed, Sep 15, 2010 at 10:58 PM, Tom van der Woerdt <i...@tvdw.eu> wrote: > 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 > -- 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