Yes, right now my server acts like an automated client for one account (never more), it handles messages and dms, follows, etc.
In my case it sounds like I'll be ok just using two connections then, one to the statuses/filter streaming api, and one to the user stream for my site's account. Though, if the site streams do offer the same Friendship, Blocks, Favorite and Retweet events, I might as well implement that way, assuming I do get granted access. Thanks for the feedback On Sep 16, 8:20 am, John Kalucki <j...@twitter.com> wrote: > 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
