I made a minor change to see if it will flush the cache. The policy is, as
of 9/1/2010:
During the beta testing period, sites are encouraged to first pull and
cross-check test data from both Site Streams and the REST API to develop
confidence in correctness and robustness. Once a Site Streams
Freakin' awesome. Nice job guys!
Jesse
On Mon, Aug 30, 2010 at 12:52 PM, Mark McBride mmcbr...@twitter.com wrote:
Site Streams, a new feature on the Streaming API, is now available for
beta testing. Site Streams allows services, such as web sites or
mobile push services, to receive real-time
My initial thought was that this was for applications like TweetDeck
where users have multiple accounts, but the docs say that Desktop
clients should keep using the normal User Streams. Will there be an
update for the User Streams to support having multiple accounts, are the
docs wrong, or do you
Desktop clients that support multiple accounts should continue to open
multiple connections on User Streams.
-John Kalucki
http://twitter.com/jkalucki
Twitter, Inc.
On Mon, Aug 30, 2010 at 12:00 PM, Tom van der Woerdt i...@tvdw.eu wrote:
My initial thought was that this was for applications
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
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
Quoting Dewald Pretorius dpr...@gmail.com:
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
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
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
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,
Ed,
Developer responsibilities and developer agreements mean absolutely
nothing to that person who wants to abuse users' DMs.
In fact, they will probably trick users to authorize their app with a
neat feature, and then in the background collect received and sent
DMs.
Twitter will not have the
Try getting access to Site Streams without a signed agreement between
your organization and Twitter prohibiting such shenanigans. ;-)
--
M. Edward (Ed) Borasky
http://borasky-research.net http://twitter.com/znmeb
A mathematician is a device for turning coffee into theorems. - Paul Erdos
I think you're missing my point. A signed agreement does not prevent
anything for the evil-minded. At best it establishes the parameters
for damage control by Twitter (revoking access, banning, etc.), except
in this case Twitter won't have the forensics to determine who did the
damage.
On Aug 30,
13 matches
Mail list logo
