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

Reply via email to