I second this request, as a mobile developer since_id is essential for caching old tweets and only retreiving new tweets.
since_id is invaluable. You say " in most cases the new approach we will take will not result in any noticeable differences " does that mean you will still handle a since_id being passed and if not how will we now use the API? On Mar 26, 8:48 pm, "Brian Smith" <br...@briansmith.org> wrote: > Any app that pages through timelines uses since_id or max_id depends > responses being ordered by tweet ID. What will be the replacement for > since_id and max_id? > > Taylor Singletary wrote: > > 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. > > 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? 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.