What we are working on…
First, I’ll introduce myself. My name is Patrick Gerzanics and I’m the Chief Software Engineer here at XC. My team and I are responsible for the development of XC Connect and XC Vault.
I just thought I’d share a bit about what my team and I are currently working on getting out to you fine people…
- Our primary focus at the moment is making our connector for Microsoft Entourage faster and more efficient. This involves a number of things, some of which we are currently putting the finishing touches on while others are still in the Development queue. Unfortunately, the way in which we are forced to interact with Entourage (Applescript scripting interface), is not very efficient for pushing large amounts of data. To address that, we are currently implementing the following:
- In the next version of the XC Connect for Entourage connector you will be able to choose the category of your personal items in regards to what is synchronized to XC Connect. As any of our Entourage users know, currently anything that is not categorized as being in a shared XC Connect folder is considered personal for XC Connect purposes. By allowing the user to specify what category contains their personal items it allows the user to restrict the amount of data involved in the synchronization process. This will speed up average synchronization times significantly as the primary bottleneck for synchronization with Entourage is the speed in which it processes requests; the less items for Entourage to process the better.For users that would still like to have all of their items considered personal, this is still available by selecting the ‘(All Categories)’ option when prompted.
- The second, and more time consuming, of the things we are doing to improve Entourage efficiency is to process items in a batched state with an intermediate data store. While testing approaches to interacting with Entourage we discovered that one of the slowest aspects of synchronization was waiting for Entourage to find an item by ID, with the time to find an item growing linearly with the number of items in the repository. Our current synchronization model processes each change as a separate request causing Entourage to find the item to modify/retrieve/delete each time.The new architecture will have an intermediate repository/cache that it stores and retrieves data from. The connector will then keep the cache in synch with Entourage as needed and communicate with Entourage via batches. This will greatly improve the efficiency of the interactions with Entourage when large numbers of items are being processed in one synchronization cycle.
- The last thing we want to address is the stability and handling of errors while interacting with Entourage. As our Entourage users know, it is not uncommon to receive the dreaded message ‘An unexpected error occurred while communicating with Microsoft Entourage…’. This was intended to be a catch-all for uncommon scenarios that have not occurred in our test environment so that we can diagnose the problem. However, our Support group has reported that the most common cause of these errors is simply that Entourage stops responding to scripting requests until it is restarted or it becomes stable. As part of the changes in item (b), the cache will allow us to handle these situations far more cleanly as they will not require the server side to recover as the cache and Entourage just need to be reconciled.
Our overall goal is to allow our Entourage users to have as seamless of a synchronization experience as our Outlook, AddressBook/iCal and Evolution users and we believe these changes will achieve that.
Unfortunately, this has run on longer then intended so I will have to post about our other upcoming feature enhancements in my next post.
Cheers.