Support Sync Framework or Move it to Open Source RRS feed

  • General discussion

  • As MSFT does not seem to be updating or supporting 2.1 they should either support the framework or move it to open source!  

    I am considering writing my own SqlExpressClientProvider as I use hub and spoke and am not that interested in using the peer to peer services.  I would really like this approach better if this was an open source project.

    Fish or cut bait!

    • Edited by PapaStoke Wednesday, March 13, 2013 7:14 PM
    Wednesday, March 13, 2013 4:39 PM

All replies

  • it's an SDK, the steps on how to create a provider is in the docs, what's stopping you from writing your own provider? that's the whole point about the SDK, having devs write their own providers if they to.  the framework doesn't need to be open-sourced to do that.  

    Wednesday, March 13, 2013 11:54 PM
  • It's more than an SDK, it's a framework - after all, what calls a custom provider? It would be nice to have the source to be able to fix bugs and add features.
    Monday, March 18, 2013 7:01 AM
  • I totaly agree with Stokes. what is the point of the sync framework if its is not updated. Who in the right mind will use it in enterprise enviroment. It has so many limitations now that it is really not funny.

    The limitiation could be maybe made better, with custom providers but maybe not all. In any way there shuld be a place where we could share the custom providers on codeplex or somewhere, can somebody make this please?

    Regards M

    Monday, March 18, 2013 8:39 AM
  • WCF is a framework, WF is a framework, WIF is a framework, but you don't see them as OSS. 

    there are frameworks that are made and designed to be extended. 

    I'd be very thrilled for them to have Sync Fx open-sourced.

    however, the question being asked as how to extend to address the specific scenario as posted above is exactly the same scenario that the extensions via custom providers is the supported way of extending Sync Fx. That's what the framework was designed for.

    just because you cant do something on it means doesn't mean it's a limitation. What if the framework was not exactly designed for your scenario? you'd blame the framework for being limited? 

    you don't need the entire code to extend it. Sync Fx Toolkit was built on top of Sync Fx, Azure Data Sync is built on top of it. and there are tons of others built on it.

    as to sharing custom providers, I've put up SyncFx Contrib on Codeplex and even emailed some people who did some work already to contribute or even provide links to their projects, but up to this day, not one has actually inquired or asked how to contribute. 
    • Edited by JuneT Monday, March 18, 2013 11:15 AM
    Monday, March 18, 2013 11:11 AM
  • JuneT - SyncFx Contrib sounds good but would be better if directly supported by MSFT in the documentation. I would take this opportunity to thank you for your support which I have found very valuable using Sync Framework.

    Take a look at this conversation back from 2009  -http://www.8bit.rs/blog/2009/05/debugging-sql-express-client-sync-provider/ concerning the sql express client provider for hub and spoke.  The entire idea of wrapping the server provider in a client shell is hokey.  If the source were available this would be a much simpler project.

    In terms of the examples you gave of frameworks that are not open source you did not mention Entity Framework which is!

    Monday, March 18, 2013 11:57 AM
  • even if they release the Sync Fx source, there is no provider for SqlExpress using the offline provider and the source for the SQL Ce offline provider wont help either because it's using a SQL CE Change tracking (and if you require having a look the change tracking, that means asking SQL Ce team to release it as well.)  The whole premise about the Local Database Cache project item was to enable a quick and lightweight client data caching capability, not SQL Replication type of synchronization (which btw, remains a valid option and has an SDK as well). 

    moreover, Sync Fx is not purely managed code, there are unmanaged components to it.

    another clarification that should be worth noting is that most people are led to believe that synchronization is just about tracking changes. Change tracking is just one aspect of it. you have to have provisioning, you have to have change tracking, you need components to do change enumeration (especially, detecting changes since the last sync), you need code to transfer the changes from one replica to another, piece of code to apply it, piece of code to detect and resolve conflicts, piece of code to keep track of what has been synched. SQL CT is just it, change tracking. using the older offline providers, you can't even switch a client to a new server.

    by tying change tracking to SQL CT or adding support to it means having different sync providers for those that use SQL CT and those that do not. So instead of having a single SQLSyncProvider now that supports SQL Express, SQL Express Local DB, SQL Server and Azure SQL Database, we would have more than one. SQL CT also meant tying up Sync Fx to what SQL CT can track. Likewise, SQL CT also meant having the provisioning/deprovisioning of CT outside of Sync Fx, even metadata cleanup. Some will be happy they dont have to do that by code, others will complain about it when they accidentally set the wrong retention period or disabled CT. (and people will start asking how to switch between CT mechanisms as well)

    But again, having said that, there is no stopping anyone from writing a custom provider for SQL Express using the offline provider approach.

    The existing file sync providers and database sync providers are technically just custom providers, built on top of the same framework.

    btw, the  "peer-to-peer" provider  can be made to sync hub-spoke. the SQL Data Sync service uses hub-spoke topology but is using the newer SqlSyncProvider peer-to-peer provider.

    • Edited by JuneT Monday, March 18, 2013 12:55 PM
    Monday, March 18, 2013 12:52 PM
  • The value  of the hub and spoke model is as you say - it is quick and lightweight.  The provisioning is very simple and practically invisible.  The change enumeration and conflict resolution implementation are simple.  I don't want or need the complexity of the peer-to-peer framework with its complex provisioning.  Kudos for making it reasonably easy to implement - but there are a large number of moving pieces and it makes me nervous. (Even futher, in my scenario, I want to log conflicts and deal with them centrally in an admin app - so all I need to do is log the conflict).  

    Perhaps I might deal with the situation better if the Framework support team came out and said "If you did Hub and spoke - sorry we are not supporting it anymore"  But that is not true.   Much of the documentation - including the SQL Server docs imply that Change Tracking is alive and supported by Sync Framework (http://msdn.microsoft.com/en-us/library/bb933994.aspx).

    Monday, March 18, 2013 7:42 PM
  • it is supported. no one says its not supported. but its supported in the older provider. and no one is saying hub and spoke is not supported either. and again, no one is stopping anyone from writing an offline provider for  sql express.  but again, the SDK doesn't have to be open-sourced to get it done. because that's the whole point about the provider model: writing providers. 
    Monday, March 18, 2013 11:55 PM
  • @JuneT - Pointing to other frameworks which aren't OSSed by MS isn't a reasonable rebuttal to the argument to why it should be open sourced. I could point to frameworks which _have_ been OSSed by MS: MVC, F#, WIX, Orchard, etc.

    By "supported" what I mean, and what I think is generally meant, isn't that you can call up and ask MS to help with problems, but that the framework received ongoing updates to the source that address user needs and issues. This is clearly not happening. I use a number of OSS libraries, as is fairly common in the .Net community at this point, and I've found bugs and feature deficiencies in them as well. The difference is I have recourse - I fix it and submit a patch. This then helps me directly, and everyone who depends on the framework. I also benefit from others doing the same thing. As it stands, there are known issues with the Sync Framework and there is no recourse - if MS doesn't correct these problems, we are all left in a bad position with no recourse with the framework. How can this sad state of affairs be defensible when MS has done OSS in the past and come away with a win/win - they keep customers on their platform and the customers have a recourse to move forward and remain with the investment on the MS platform.

    Tuesday, March 19, 2013 6:58 PM
  • my point is just because its a framework doesn't mean it should be open sourced as a reply to this: "It's more than an SDK, it's a framework".

    It's also not a reasonable rebuttal that because other products has been open-sourced, then we should have this one too.

    As i have mentioned, I'd be happy for MS to have this open-sourced and i brought this up with others many times.  I'm not against OSS.

    But to say this should be open sourced so that i can write a custom sync provider is missing the point of the SDK. The SDK has been designed for such, writing custom providers. In fact, the issue being raised by the original poster has a workaround. You don't need the source to do it.

    On another note, MS has even open-sourced the Sync Fx Toolkit so people can extend to non-MS platforms. 2 years onwards, i have yet to see a sizeable contribution to it.

    With regards to supportability, it is a supported product. You can raise a bug via the formal channel and I've seen in several scenarios where MS has issued a fix. 

    • Edited by JuneT Wednesday, March 20, 2013 12:09 AM
    Wednesday, March 20, 2013 12:07 AM