Why a 2.6.7 Version of Inbox?

[As I said in my previous post, if you have feeds that are synchronized with NewsGator Online and are reporting errors, no longer downloading new items or have items that are not synchronizing with NewsGator Online, please upgrade to Inbox version 2.6.7]

This morning I got to work thinking that I would finish up my testing on NewsGator Desktop Sync so that it was ready for public beta on Monday... instead I created, tested and released a new version of NewsGator Inbox.  Needless to say it was a pretty crazy day.

Inbox version 2.6.7 contains only one critical fix for users who synchronize with NewsGator Online.  I'll go into more detail about that a little further down. 

In order to get this out in less then a day, I had to roll back my code to 2.6.6 (thank you Vault for making this so easy) and just make this one change.  Many of the bugs that have been reported since 2.6.6 was released have been fixed and more are in development, but releasing a version with those fixes and without any real world testing was just too risky.  Please know that we have another release in development that will include those fixes as well.

So why such a fast release of 2.6.7?
Sometime early Friday morning MST, the NewsGator platform downloaded it's 2,147,483,649th post.  That's actually pretty amazing... but why does it matter? 

The NewsGator platform assigns each post a unique ID.  This ID is an ever growing number that identifies each post.  These post ID's are represented in the NewsGator API as strings and are used as strings in 99% of Inbox.  The problem was that 1%.

Computers and programming languages are very smart about how much actual memory something should take up.  An integer is almost universally represented using 32 bits for positive only values and 31 bits for positive/negative values.  This means that you only have 2^31 values for signed integers... or 2,147,483,648 actual values (you can double this by using that last 32nd bit and negative numbers or by using only absolute values). 

To go beyond that, you have to use something else that uses more memory but can represent more numbers.  In programming languages we usually call this a Long or a 64 bit integer... this gives you 18,446,744,073,709,551,616 signed values or 36,893,488,147,419,103,232 unsigned values.

Using strings, which Inbox does 99% of the time to identify posts, totally circumvents you from this problem since they will take as much memory as they need - your computer won't try to stuff them into a set size.

When a post is synchronized with NewsGator Online, the Post ID (the string from NewsGator) is used.  When a feed is not synchronized, the Entry ID (a string assigned by Outlook) is used.  Entry ID's from outlook are a unique combination of letters and numbers, so to the human eye they're very distinguishable.  In code, the easiest way to tell them apart is to see if the computer can successfully convert the string to some numeric value.

That's the bug!  I was trying to change these strings only into integers.  Once the NewsGator Post ID's went beyond the limit of an integer, my test failed and essentially broke Inbox's synchronization.

Lesson Learned
The NewsGator Platform never hiccupped when the Post ID's got to where they are.  It expected it, knew it was coming, and kept chugging right along.  Inbox would have, if it wasn't for a small piece of code that I wrote almost two years ago that assumed that the value could always be represented by an integer.

Why am I telling you the gory details?  One - you should know why you need to upgrade.  Two - the problems of Y2K aren't just about dates. 

I graduated college in 2001, and though I was very well schooled in the problems of the Y2K bug, I always equated it to a problem with dates and not data in general... and as any developer will tell you, until you get really bitten by a bug like this its not something that's front of mind.   

Hopefully my experience will make other developers more aware!