Adding more structure to the "masterVersion" concept

[crspybits]

Jim Dotter came up with the idea of making the masterVersion hierarchical. For me, this means informing the server more about the app data model. What I'd been trying accomplish is make sure that changes that the user made to their data were informed by the data state on the server. The master version lets you do that in an all or nothing manner-- i.e., it's very coarse. Let's say, however, for example the app UI had two independent screens. Then the user should be able to make changes on one screen independent of the other screen. Thus, having a single master version integer would be overly restrictive-- as it models just one collection of data. What we need in this case is to inform the server that we have two collections of data. So, effectively two "sub master versions" (two integer values) might be appropriate-- one reflecting the data behind each screen. So if the user made a change to screen 1, only the sub master version (call these subMasterVersion1, and subMasterVersion2) for that screen would be relevant. The user makes a change to screen one and if subMasterVersion1 on the server hasn't changed recently, then that change could be uploaded to the server. subMasterVersion2 might have changed, but since that's an independent part of the app, that's ok.