I want to thank everyone who has contacted me (via email, Twitter, etc) about EasySync. I appreciate your interest, and apologize for not being able to get back to many of you. I'm juggling several projects at the moment, and it has been yet another hectic week.
I am being asked a lot of really good questions about EasySync, both by those of you have read about it, and those who I have had a chance to demo it to. I thought it might be easier to answer those questions here.
Why are you developing EasySync?
I've had the idea for something like EasySync for about a year now, but haven't had a chance to do anything with it. Recently, I was speaking with a client who expressed interest in adding sync support to his FileMaker Go-based solution. So it seemed like as good a time as any to spend some time on the idea, and see if anything would come of it.
And I am glad that I waited to act on the idea, because EasySync wouldn't be possible without some of the new functionality that we now have with the FileMaker 13 platform. For example, without support for Base64 encoding and decoding, the "payload" concept that is so critical to EasySync wouldn't be possible - at least as far as handling containers goes. "Perform Script on Server" is also very important, because it allows EasySync to push payloads from the mobile device to the server, where they can be processed more efficiently.
Is EasySync transactional?
Yes, it is. Without going into great detail, the sync process essentially works like this:
The mobile device initiates the sync process.
A payload is created that contains all of the data that has been added, or changed, on the mobile device since the last sync.
That payload is delivered to the server.
A request is sent to the server (using "Perform Script on Server") to process the payload.
The server receives the request, and confirms that the payload is well formed.
It then starts to apply the changes, and treats them as a transaction. If any errors are encountered, the changes are rolled back.
A response is sent back to the mobile device indicating whether the sync was successful or not.
The "pull" phase of the sync process works in a very similar way, and is essentially a mirror image of the process described above. The difference, of course, is that the server creates and hands off a payload to the mobile device, and the mobile device processes it. (The code used for the "push" and "pull" phases is very similar.)
Why did you decide to go "open source" with EasySync?
Surprisingly (to me anyway), this is one of the questions that I am being asked the most. There were several reasons why I decided to make EasySync open source:
I want to give back to the FileMaker community, and this seems like a great way to do that.
I think that by sharing EasySync with other developers, it will evolve and become an even better solution.
I'm curious to see how people will use it. I've already spoken with several developers who are planning to use it on client projects, and I have been excited to hear about them.
Where are things now?
The original proof-of-concept supported only the "push" phase of a sync between the mobile device and the hosted database. I'm happy to report that EasySync now supports the "pull" phase as well. So EasySync is now bi-directional.
There have been several other enhancements that I've made over the past few days. They include conflict resolution (where data has been changed on both the mobile device and the server since the last sync), support for excluding certain records from the "push" payload, additional configuration options, and more.
What challenges are you facing?
None at the moment, other than a serious lack of sleep and an inbox that needs some attention.
I think most of the technical hurdles have been overcome. The biggest challenge was in handling the delivery of the payload from the mobile device to the server. I had hoped to do this by passing the payload as a parameter using the new "Perform Script on Server" script step, but discovered that the size of the script parameter that it supports is limited. From what I can tell the maximum size supported is a million characters. That seems like a lot, and 99.9% that should be more than sufficient. But when you're working with Base64-encoded data, it is easy to hit that limit. In any case, I did find a workaround for this.
What still needs to be done?
I am enhancing the "pull" process a bit, to make it more efficient. I also want to provide support for handling deleted records, which is complicated. I also need to document everything, put together a more complex demo database, and then figure out how to make EasySync available for download.
When will EasySync be available?
EasySync is evolving very quickly. If everything goes as planned, I will be releasing it towards the later part of next week. Also, because of all of the interest, I am considering holding a GoTo meeting (or something similar) to demo EasySync and answer questions.
For updates on EasySync, please follow me on Twitter: @tdietrich