1:20 PM
*To:* twitter-development-talk@googlegroups.com
*Subject:* Re: [twitter-dev] Re: Upcoming changes to the way status IDs
are sequenced
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors and just what QoS
...@googlegroups.com] On Behalf Of John
Kalucki
Sent: Friday, April 09, 2010 3:31 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs
are
sequenced
Your second paragraph doesn't quite make sense. The period between your
next
On Sun, Apr 11, 2010 at 5:14 PM, John Kalucki j...@twitter.com wrote:
This is useful stuff for dealing with infinite sequences of events -- like,
picking a random example, the insertion of new tweets into a materialized
timeline (a cache of the timeline vector).
The Twitter stream is an
On Thu, Apr 08, 2010 at 05:03:29PM -0700, Naveen wrote:
However, I wanted to be clear and feel it should be made obvious that
with this change, there is a possibility that a tweet may not be
delivered to client if the implementation of how since_id is currently
used is not updated to cover the
a much more naive
approach to pagination.
Thanks again,
Brian
From: twitter-development-talk@googlegroups.com On Behalf Of John Kalucki
Sent: Friday, April 09, 2010 1:20 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs
@googlegroups.com
*Subject:* Re: [twitter-dev] Re: Upcoming changes to the way status IDs
are sequenced
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors and just what QoS we're really offering
@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors and just what QoS we're really offering. This new scheme
Thank you for the feedback. It's great to hear about the variety of use
cases people have for the API, and in particular all the different ways
people are using IDs. To alleviate some of the concerns raised in this
thread we thought it would be useful to give more details about how we plan
to
On Thu, Apr 1, 2010 at 10:47 AM, Dewald Pretorius dpr...@gmail.com wrote:
Mark,
It's extremely important where you have two bots that reply to each
others' tweets. With incorrectly sorted tweets, you get conversations
that look completely unnatural.
I'd love to see an example of two bots
On Thu, Apr 8, 2010 at 5:39 PM, Nick Arnett nick.arn...@gmail.com wrote:
I'd love to see an example of two bots replying to each other and looking
entirely natural!
We all knew this sort of thing was going on, removing the pesky humans from
the loop, but I always thought it was
...@googlegroups.com] On Behalf Of Mark McBride
Sent: Thursday, April 08, 2010 5:10 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Thank you for the feedback. It's great to hear about the variety of use cases
-development-talk@googlegroups.com [mailto:
twitter-development-t...@googlegroups.com] On Behalf Of Mark McBride
Sent: Thursday, April 08, 2010 5:10 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Thank
: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
It's a possibility, but by no means a probability. Note that you can mitigate
this by using the newest tweet that is outside your danger zone. For example
in a sequence of tweets t1, t2 ... ti ... tn with creation
On 04/05/2010 12:55 AM, Tim Haines wrote:
This made me laugh. Hard.
On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius dpr...@gmail.com wrote:
Mark,
It's extremely important where you have two bots that reply to each
others' tweets. With incorrectly sorted tweets, you get conversations
Just out of curiosity, what applications are you building that require
sub-second sorting resolution for tweets?
---Mark
http://twitter.com/mccv
On Wed, Mar 31, 2010 at 11:01 PM, Aki yoru.fuku...@gmail.com wrote:
It actually makes sense to use tweet ID to sort tweets, because
timestamp is
On Wed, Mar 31, 2010 at 07:30:00AM -0700, eugene.man...@gmail.com wrote:
Second that. Our app continuously retrieves feeds of individual users
and lists. Monotonically increasing are required to be able to do that
(using since_id).
[...]
Since the most significant bits are generated from a
So I think we need to allow Twitter some leeway here.
I apologize if my tone came off badly; it was not intended. I've just
had bumpy rides using timestamps for coordination in distributed
systems (less cool ones than space flight), so this worried me a
little. In the end, whatever Twitter
So, I guess for the since_id issue, it boils down to this question:
Regarding the since_id parameter, when you (Twitter) flip the switch
on the new ID format, will I (as a developer) have to change any of my
code in order for it to function the way it does now? This question
applies equally for
I hope you're right, but my app design depends on since_id, and before I
proceed further I want to be sure that I will not have to rebuild when this
new format comes in.
On 26 March 2010 21:09, Ray Krueger raykrue...@gmail.com wrote:
I would think that this would make no difference for
I am still a little unclear if we will be able to determine the correct
since_id to pass to the api by always looking for the largest tweet id we have
seen.
It seems if two messages are posted at very close to same time, they may not be
sequential since the bottom bits will be randomly
Hi Taylor (et al.),
There are two reasons to think that, with the scheme you propose,
tweet ids will not necessarily be monotonically increasing.
Naveen hit the first:
It seems if two messages are posted at very close to same time, they may not
be sequential since the bottom bits will be
22 matches
Mail list logo
