Re: [twitter-dev] Question about User Vs Site Streams, and Moving away from REST calls.
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
Re: [twitter-dev] Question about User Vs Site Streams, and Moving away from REST calls.
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 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
Re: [twitter-dev] Question about User Vs Site Streams, and Moving away from REST calls.
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
