John, That page still says exactly the same.
On Aug 30, 5:24 pm, John Kalucki <j...@twitter.com> wrote: > It's cached. It'll update via a process that is mysterious to me. > > > > On Mon, Aug 30, 2010 at 1:21 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > > John, > > > Is that page cached, because the third sentence of the first bullet > > under Important Items still says *exactly* the same? > > > On Aug 30, 5:15 pm, John Kalucki <j...@twitter.com> wrote: > > > Thanks. I've clarified the language. > > > > -John > > > > On Mon, Aug 30, 2010 at 12:42 PM, Dewald Pretorius <dpr...@gmail.com> > > wrote: > > > > John, > > > > > Perhaps you should then rephrase the following at > > > >http://bit.ly/sitestream_doc > > > > > "One Site Streams graduates to production, sites must only use the > > > > REST API for data that is not available through User Streams or as a > > > > fall-back data source." > > > > > It's in the first paragraph of Important Items. > > > > > Here's another issue that probably needs to be considered. > > > > > It applies mostly to DMs, because people will tend to use DMs for > > > > sensitive information, and would expect a certain level of privacy. > > > > > Right now, an OAuth authorized site can query a user's DMs and do with > > > > that info what it likes. It could present privacy issues, but at least > > > > you have an audit trail of the DM request by the authorized site in > > > > your logs/system. > > > > > You lose that audit trail with Site Streams. The DMs are > > > > indiscriminately distributed out to all OAuth authorized sites that > > > > subscribe to the user's stream. > > > > > It may not seem like a big deal, because it's status quo minus the > > > > audit trail. Until you're hit with a multi-million dollar class-action > > > > lawsuit for indiscriminately distributing potentially sensitive > > > > information. Then it is a big deal. It's not only the lawsuit, it's a > > > > privacy PR disaster as well. > > > > > On Aug 30, 4:25 pm, John Kalucki <j...@twitter.com> wrote: > > > > > We're not forcing people over to Site Streams. If, on the other hand, > > if > > > > you > > > > > start to consume Site Streams, we want you to stop regular polling on > > the > > > > > REST API. > > > > > > If your service is modest, any excess delivery will be modest. > > Excessive > > > > > options add complexity and slow development for what may be little > > > > > practical efficiency gain. Bandwidth and CPU are nearly free at > > > > 1mbit/sec. > > > > > It's all a balance. > > > > > > -John Kaluckihttp://twitter.com/jkalucki > > > > > Twitter, Inc. > > > > > > On Mon, Aug 30, 2010 at 12:15 PM, Dewald Pretorius <dpr...@gmail.com > > > > > wrote: > > > > > > This is super news. > > > > > > > However, if you're going to force web services to use Site Streams > > > > > > when it is in production ("sites must only use the REST API for > > data > > > > > > that is not available through User Streams"), then please add the > > > > > > ability to subscribe only to certain elements. For example, we need > > > > > > the ability to subscribe to only Follows, or to only Tweets and > > > > > > Retweets, etc. > > > > > > > You make note that each stream may consume significant bandwidth (> > > > > > > 1MB). > > > > > > > If a web service does not make use of the user's Follows, or of the > > > > > > user's Tweets, then it makes no sense to consume that bandwidth > > with > > > > > > the dead-weight of the elements that are not used by the service. > > > > > > > I understand that Site Streams is in beta now. I'm putting in this > > > > > > request for when it is in production and we are forced to use it. > > > > > > > -- > > > > > > 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
