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

Reply via email to