"EasySync Beta 8" is nearly ready to go. I wrapped things up very early this morning. In it you will find:
"Round-Tripping" Data During Syncs
In this version I made the difficult decision to "round trip" the data - meaning that data being pushed up to the server is immediately included in the pull payload that follows. I tried everything that I could think of to avoid this, but in doing so there were times where a user - especially one syncing using the same account across multiple devices - would end up not receiving some of the data during the pull process. This also had the potential to take data out of sync depending on what conflict resolution method is being used. There was the possibility that a mobile user would "lose" when a conflict arose, and as a result a local record might not reflect what was actually on the server. So "round tripping" the data became a necessity.
Performance Improvements When Processing Payloads
During the processing of the records portion of the payloads, EasySync now searches for the closing "</records>" tag starting at the end of the payload (instead of the from the beginning). This minor change improves speed slightly. Thanks go out to Daniel Wood (Twitter: @FMweetbicks) for the suggestion.
EasySync Beta 8 includes code that supports my take on how a developer might choose to handle the syncing of deletions. Some of you will like it, others won't. But it is a start, and it works.
"Partial Push" Example Code
The demo database will include code that shows how a developer might choose to add support for pushing a subset of the local data (something that I have been referring to as a "partial push"). It is by no means perfect, but it works.
I am planning to release Beta 8 later this week. It needs some additional fine tuning and testing before I'll feel good about releasing it.
My plan is to resolve any bugs that are reported in Beta 8, and then ship EasySync v1.0. That will most likely happen May 1st, depending on the severity of any bugs that are reported.
And at that point, I'm planning to pass the torch to some degree.
I feel very strongly that if EasySync is going to be successful, it needs to be designed and developed based on more than just my own opinions, skills, and experience. Therefore, I'm hoping to form something along the lines of an advisory group that will help take EasySync forward. That group will decide what features to implement, how to handle technical support, how to promote EasySync, and so on.
As it stands today, EasySync meets the needs of a good many of my own clients. I know EasySync isn't the be all and end all of sync, and I'm fully aware that there are other sync solutions available that in many cases might be a better fit for some developers. Regardless, I feel good about my decision to put EasySync "out there" as they say, and hope that it will help other developers create sync solutions that meet their own needs.
Thanks again for all of the feedback, ideas, and suggestions about EasySync. And please stay tuned as things progress.