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 generated and I will not be able to safely just always use the largest id I have seen as the since_id?? Correct me if I am confusing myself please. On Mar 26, 2010, at 5:33 PM, Taylor Singletary wrote: > A quick clarification for you all since there seems to be the most concern > around using since_id as a parameter: > > since_id will work as well as it does today as a result of this change. > > Also, a reminder that the actual integer format of the tweet IDs will not be > changing. They'll still be unsigned 64bit integers as they are today. > > Taylor Singletary > Developer Advocate, Twitter > http://twitter.com/episod > > > On Fri, Mar 26, 2010 at 1:41 PM, 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 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, Twitter > http://twitter.com/episod > > > To unsubscribe from this group, send email to > twitter-development-talk+unsubscribegooglegroups.com or reply to this email > with the words "REMOVE ME" as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
