I think you can only really rely on IDs having different values.

In general, at the moment with Twitter, you could assume they increase over 
time, but (and I don't work for Twitter) typically ID allocation on large 
multihost systems don't work by allocating strictly sequential IDs without 
gaps - it's too hard to sequence and not really necessary.

So, for example, one way is that you build a system that gives different 
ID-assigning-hosts small blocks of IDs that they can use so they can 
allocate a series of IDs knowing they're unique without having to take out 
any kind of global lock (they only take the lock to ask for a new block 
every now and then). Another approach might be to have clocks synchronised 
to some known accuracy and have IDs calculated as "period-since-epoch * 
some-suitable-multiplier + unique-offset-per-host + 
incrementing-counter-for-this-host". 

I'm sure people can come up with other schemes as quick as we could type 
them up, but in general you make your ID space many orders of magnitude 
bigger than you strictly need, and in return you gain some flexibility in 
the criteria needed for quick and cheap unique allocation in a distributed 
system. But I wouldn't assume that every possible ID value is necessarily 
allocated.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to