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.

Reply via email to