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

Reply via email to