2009/5/13 John Kalucki <jkalu...@gmail.com> > > I'll attempt to answer these questions, but I can only do so with some > speculation and humble ignorance. > > 1) OAuth allows clients to authenticate with the Twitter REST API via > third-party services. These services should not also need to interact > with the Streaming API on a per client basis. Instead, the service > should establish a single query that satisfies all clients' needs. > This may not be practical in all cases, but I suspect we can > approximate the desired behavior with the current set of primitives. >
John, in your original mail on this thread you wrote: For example, a desktop client could simulate a user's /home timeline, minus private updates and mentions, via the "/follow" resource. Continuous polling would no longer be necessary or desired. This doesn't match the scenario from above, where you refer to using the streaming endpoints from a single query per service. So still the question how a desktop client that is trying to do OAuth and not ask users for their passwords can use the streaming API is open - or are you saying that those clients just cannot use it? I think this would discourage many desktop developers from even looking into integrating OAuth for their clients, which as I assume can't be in twitter's interest. > 2) There are no immediate plans to support HTTPS, mainly because we're > not really trying to keep the data private. Also, and I am probably > totally wrong here, I don't think we use HTTPS on the main WWW site or > on the REST API, so this doesn't make things much worse than they > already are. A possible workaround would be for sensitive service to > create an account just for streaming. Should the password be > compromised, there's only a denial of service risk and no further > risk. > Again, this doesn't help much in the context of desktop app use, as it would have to use it's authenticated user's credentials. Clients just shouldn't send a cleartext password over an unecrypted connection IMO. Marco > On May 13, 11:18 am, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > > John, > > > > this looks pretty interesting! > > > > Two questions: > > > > 1) you are requiring to send a username and password for Basic Auth - how > > does that map to apps / services using OAuth, as they won't have access > to a > > user's passwords? (and related, how does this fit into your general > roadmap > > to move everything to OAuth?) > > > > 2) the docs only mention http as a protocol, not https. In combination > with > > requiring passwords, only making http available seems quite unsecure. Any > > plans to also support https soon (or any other mechanism which gives > better > > security?) > > > > Thanks, > > Marco > > > > 2009/5/13 John Kalucki <jkalu...@gmail.com> > > > > > > > > > Chad, > > > > > Yes, I think this is called POSTDATA in browsers. I don't recall what > > > the actual name of this part of the HTTP protocol is, but it's the > > > body section after the headers. > > > > > I corrected the file name error. Thanks. > > > > > -John > > > > > On May 12, 8:49 pm, Chad Etzel <jazzyc...@gmail.com> wrote: > > > > Hi John, > > > > > > /follow looks very interesting. Since you're asking for feedback.... > > > > > > I'm copying the "follow parameter" example documentation: > > > > > > Example: Create a file called 'follow' that contains, exactly and > > > > excluding the quotation marks: "follow=12 13 15 16 20 87". Execute: > > > > curl -d @followinghttp://stream.twitter.com/follow.json > > > > -uAnyTwitterUser:Password.You will receive JSON updates from Jack > Biz, > > > > Crystal, Ev, Krissy, but not from Jeremy, as he's a private user. > > > > > > I'm assuming that "follow" is just a POSTDATA variable in the normal > > > > case (you're just using curl's file posting ability in the example)? > > > > > > In the example, should the file be called "following" instead of > > > > "follow" (since you are using -d @following in the curl line)? > > > > > > Thanks, > > > > -Chad > > > > > > On Tue, May 12, 2009 at 11:24 PM, John Kalucki <jkalu...@gmail.com> > > > wrote: > > > > > > > Note: The Streaming API is currently under a limited alpha test, > > > > > details below. > > > > > > > The "/follow" Streaming API resource is now publicly available. > This > > > > > resource streams near-real-time public updates posted by an > arbitrary > > > > > set of users. Streaming by user_id may be interesting to a variety > of > > > > > developers who wish to provide a nearly instantaneous experience > > > > > without the drawbacks of continuous polling, polling rate limits, > auto- > > > > > following and follow limits. > > > > > > > For example, a desktop client could simulate a user's /home > timeline, > > > > > minus private updates and mentions, via the "/follow" resource. > > > > > Continuous polling would no longer be necessary or desired. Upon > > > > > receipt of a new streamed message, the REST API may be periodically > > > > > polled to back-fill mentions, private statuses and other updates > not > > > > > available via the Streaming API. > > > > > > > This stream may also be interesting to service developers that > follow > > > > > their subscribers solely to receive their replies or for data > mining > > > > > purposes. Auto-following, following limit and rate limit hassles > could > > > > > be exchanged for real-time streaming subscriber updates. > > > > > > > Currently this resource is limited to following 200 user_ids. > > > > > Developers requiring considerably more followings and/or > back-filling > > > > > via the "count" parameter should consider applying for the > restricted > > > > > "/shadow" resource. > > > > > > > Feedback is encouraged as we determine the ease-of-use, value, > tuning > > > > > and operational viability of this resource. With any luck, > streaming > > > > > might also be easier on the Twitter service. Our flock of orange > whale- > > > > > hoisting birds are pretty tuckered out. > > > > > > > Important Alpha Test Note: > > > > > The Streaming API (aka Hosebird) is currently under an alpha test. > All > > > > > developers using the Streaming API must tolerate possible > unannounced > > > > > and extended periods of unavailability, especially during > off-hours, > > > > > Pacific Time. New features, resources and policies are being > deployed > > > > > on very little, if any, notice. Any developer may experiment with > the > > > > > unrestricted resources and provide feedback via this list. Access > to > > > > > restricted resources is extremely limited and is only granted on a > > > > > case-by-case basis after acceptance of an additional terms of > service > > > > > document. Documentation is available: > > >http://apiwiki.twitter.com/Streaming-API-Documentation. >
