Some existing MS sync technologies such as Mesh (FeedSync) and Sync FX are compatible on sync metadata level, therefore one can think of them as different ways to achieve the same goal. FeedSync is all about open Web standards such as RSS/Atom and Sync FX is
a generic framework for building arbitrary sync solutions. I can't comment on SQL Server Merge replication now.
1) Mesh has a slightly different requirements and therefore they use FeedSync as the default data and synchronization metadata representation format. The primary reason I believe was that Mesh wanted to use open and Web specific RSS/Atom-based format. That's
what FeedSync is perfect for. This aligns well with the Sync FX which abstracts itself away from the protocol and data format business. For example, Sync FX supports interop with FeedSync (i.e. you can consume or produce a FeedSync RSS/Atom feed) and transforms
Sync FX's sync metadata such as knowledge to/from FeedSync sync metadata.
2) Sync FX is not any transport specific, therefore if sync providers choose to use NAT-friendly transport then yes.
The Sync Framework is data and protocol agnostic, therefore it's up to your implementation when to start a sync session. For example, your sync application can be written in such a way that once a connection between endpoints is detected, you can start sync
session right away. From the Sync Framework's perspective, both providers are running in the same process on the same machine. A provider can be written to support remote processing over arbitrary protocol and transport. You can find Sync Framework samples
at http://code.msdn.microsoft.com/sync. All information about Sync FX is available at
http://msdn.microsoft.com/sync.
Synchronizing Data: Inside the Microsoft Sync Framework
Aug 22, 2008 at 11:39 AMSome existing MS sync technologies such as Mesh (FeedSync) and Sync FX are compatible on sync metadata level, therefore one can think of them as different ways to achieve the same goal. FeedSync is all about open Web standards such as RSS/Atom and Sync FX is a generic framework for building arbitrary sync solutions. I can't comment on SQL Server Merge replication now.
For overview of benefits please refer to http://msdn.microsoft.com/en-us/sync/default.aspx, particularly http://msdn.microsoft.com/en-us/sync/bb887625.aspx.
HTH
Synchronizing Data: Inside the Microsoft Sync Framework
Aug 22, 2008 at 11:33 AM1) Mesh has a slightly different requirements and therefore they use FeedSync as the default data and synchronization metadata representation format. The primary reason I believe was that Mesh wanted to use open and Web specific RSS/Atom-based format. That's what FeedSync is perfect for. This aligns well with the Sync FX which abstracts itself away from the protocol and data format business. For example, Sync FX supports interop with FeedSync (i.e. you can consume or produce a FeedSync RSS/Atom feed) and transforms Sync FX's sync metadata such as knowledge to/from FeedSync sync metadata.
2) Sync FX is not any transport specific, therefore if sync providers choose to use NAT-friendly transport then yes.
HTH
Synchronizing Data: Inside the Microsoft Sync Framework
Aug 21, 2008 at 6:17 PMThe Sync Framework is data and protocol agnostic, therefore it's up to your implementation when to start a sync session. For example, your sync application can be written in such a way that once a connection between endpoints is detected, you can start sync session right away. From the Sync Framework's perspective, both providers are running in the same process on the same machine. A provider can be written to support remote processing over arbitrary protocol and transport. You can find Sync Framework samples at http://code.msdn.microsoft.com/sync. All information about Sync FX is available at http://msdn.microsoft.com/sync.