I'm not sure these statements fit into the nomenclature of Microsoft.Synchronization, but hopefully you will get the gist. In our sync, there are a number of different data objects and by the object type, one side of the sync has authority. We
don't have a unique syncID by row or anything like that. For about half of the objects, one side of the sync is the authority, and for the rest, the other participant has authority. So in a lot of ways, our program is just a fancy data copy, but
we want to avoid duplicates and for that, we have different columns by authority for the datatype that will give us what we need to say yes or no to creating/deleting or over writing the record.
We aren't tracking anything about what was sync'd. Based on authority and some custom fields, we sync or not. Given that, we don't really need to keep track of what record has changed, accept in a situation where we have a conflict and even in
those cases, we will just assume the side of the sync that has authority for that object becomes the new data and over write the non-authoritative data. The entire part of the Microsoft.Synchronization namespace that deals with Metadata and its storage,
we don't need.
Why I originally thought we would use a simple custom provider. However, when I dug further into the requirements of a simple custom provider, it says it only syncs 1 type of data. That has me scratching my head as well. Since a requirement
of a simple custom provider is that it only sync 1 type of data, and I have about 15 different types of data to sync, do I build 15 simple custom providers or do I create a managed custom provider that can handle these 15 different types of data?
Then add onto that, one of the sync servers, I access via a webservice, the other side I access via WCF.
I'm I barking up the wrong tree here thinking about using Microsoft.Synchronization?
