We truly and sincerely want support this use case as soon as we possibly can. To do so is a big win for everyone.
If we can hack something together, even at considerable expense, we will do so. There isn't a clear path, as our options are limited due to authentication, privacy, capacity and logistics issues. We'll continue to game out various acceleration possibilities as we get user streams ready to launch over the next several months. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Thu, Apr 22, 2010 at 7:25 AM, Darren Bounds (Cliqset) <dar...@cliqset.com> wrote: > Hello! > > While it has been documented that the Twitter User Streams API is > designed predominantly for server-2-client interactions, I'm wondering > how Twitter feels about a service provider (like Cliqset) attempting > to behave within the bounds of a typical User Streams usage pattern. > > At a high level what I mean by 'behave' is that the Cliqset website > would exhibit the behavior of a desktop application, establishing > connectivity to the User Stream only when Twitter user was active > within the application. The only caveat would be the need for multiple > authenticated connections from 1 or more hosts. > > Is this something that would be frowned upon by Twitter or can we > explore this further? > > Thanks, > > Darren > > > -- > Subscription settings: > http://groups.google.com/group/twitter-development-talk/subscribe?hl=en >
