This made me laugh. Hard. On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius <[email protected]> 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. > > On Apr 1, 1:39 pm, Mark McBride <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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 > have > > > > 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 > that > > > storm > > > > with ease. The tweetapoclypse was averted, and the tweets kept > flowing. > > > > > > 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 > approach > > > 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 > 64-bit > > > > unsigned integers. However, this new solution is no longer guaranteed > to > > > > generate sequential IDs. Instead IDs will be derived based on time: > the > > > > 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 > infrastructure > > > > needs evolve, we might need to tweak the generation algorithm again. > > > > > > If you've been trying to divine meaning from status IDs aside from > their > > > > role as a primary key, you won't be able to anymore. Likewise for > usage > > > of > > > > IDs in mathematical operations -- for instance, subtracting two > status > > > IDs > > > > to determine the number of tweets in between will no longer be > possible. > > > > > > For the majority of applications we think this scheme switch will be > a > > > > non-event. Before implementing these changes, we'd like to know if > your > > > > applications currently depend on the sequential nature of IDs. Do you > > > depend > > > > on the density of the tweet sequence being constant? Are you trying > to > > > > analyze the IDs as anything other than opaque, ordered identifiers? > Aside > > > > for guaranteed sequential tweet ID ordering, what APIs can we provide > you > > > 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 - >
