I'm developing desktop Twitter client. I think accurate sorting is needed, because the order of tweets may look different on every application without accurate sorting. It's not that it would totally kill my Twitter client, but I take accurate presentation of tweets seriously, and I think it would be better to have consistent tweet ordering across all applications.
If this scheme change is really needed (e.g. required to processing new tweets simultaneously across multiple servers without synchronising tweet ID), I would suggest adding time in milliseconds to tweet information, which would have much better accuracy. On Apr 2, 3:39 am, 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.
