This made me laugh. Hard.
On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius <dpr...@gmail.com> wrote:
> 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.
> On Apr 1, 1:39 pm, Mark McBride <mmcbr...@twitter.com> wrote:
> > 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 not a valid source of information for accurate sorting.
> > > It is a very common case to have multiple tweets posted at the exact
> > > same second, and it is not possible to reproduce the correct ordering
> > > of tweets on the client side. This can be improved by having better
> > > precision for timestamp (maybe milliseconds), but it is still possible
> > > to get tweets posted at the exact same milliseconds (although it is
> > > very rare).
> > > If Twitter really needs to change the tweet ID scheme, I think better
> > > solution for sorting is required to be provided through API.
> > > On Mar 27, 7:41 am, Taylor Singletary <taylorsinglet...@twitter.com>
> > > wrote:
> > > > Hi Developers,
> > > > It's no secret that Twitter is growing exponentially. The tweets keep
> > > coming
> > > > with ever increasing velocity, thanks in large part to your great
> > > > applications.
> > > > Twitter has adapted to the increasing number of tweets in ways that
> > > > affected you in the past: We moved from 32 bit unsigned integers to
> > > 64-bit
> > > > unsigned integers for status IDs some time ago. You all weathered
> > > storm
> > > > with ease. The tweetapoclypse was averted, and the tweets kept
> > > > Now we're reaching the scalability limit of our current tweet ID
> > > generation
> > > > scheme. Unlike the previous tweet ID migrations, the solution to the
> > > current
> > > > issue is significantly different. However, in most cases the new
> > > we
> > > > will take will not result in any noticeable differences to you the
> > > developer
> > > > or your users.
> > > > We are planning to replace our current sequential tweet ID generation
> > > > routine with a simple, more scalable solution. IDs will still be
> > > > unsigned integers. However, this new solution is no longer guaranteed
> > > > generate sequential IDs. Instead IDs will be derived based on time:
> > > > most significant bits being sourced from a timestamp and the least
> > > > significant bits will be effectively random.
> > > > Please don't depend on the exact format of the ID. As our
> > > > needs evolve, we might need to tweak the generation algorithm again.
> > > > If you've been trying to divine meaning from status IDs aside from
> > > > role as a primary key, you won't be able to anymore. Likewise for
> > > of
> > > > IDs in mathematical operations -- for instance, subtracting two
> > > IDs
> > > > to determine the number of tweets in between will no longer be
> > > > For the majority of applications we think this scheme switch will be
> > > > non-event. Before implementing these changes, we'd like to know if
> > > > applications currently depend on the sequential nature of IDs. Do you
> > > depend
> > > > on the density of the tweet sequence being constant? Are you trying
> > > > analyze the IDs as anything other than opaque, ordered identifiers?
> > > > for guaranteed sequential tweet ID ordering, what APIs can we provide
> > > to
> > > > accomplish your goals?
> > > > Taylor Singletary
> > > > Developer Advocate, Twitterhttp://twitter.com/episod
> > > --
> > > To unsubscribe, reply using "remove me" as the subject.- Hide quoted
> text -
> > - Show quoted text -