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

Reply via email to