[commits] [Wiki] changed: ActiveSync

[Jan Schneider]

jan  Thu, 05 Jan 2012 12:02:52 +0100

Modified page: http://wiki.horde.org/ActiveSync
New Revision:  120
Change log:  Add Horde/Z-Push comparison

@@ -106,8 +106,43 @@

  <code>
  tshark 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -  
((tcp[12]&0xf0)>>2)) != 0)' -w /path/to/capture/file
  </code>
+
+++ Horde_ActiveSync vs. Z-Push
+
+Horde_ActiveSync was based on Z-Push. The code that handles the  
protocol level is essentially the same, though it has been heavily  
refactored and cleaned.
+
+Z-Push comes out of the box with a number of backends. The only one  
that is really //fully// functional is the "ICS" backend which  
connects to a Zarafa server. In addition to the ICS backend, Z-Push  
also provides a number of other backends - all of which extend what  
they call the "Diff" backend.
+
+The diff backend is a very inefficient way of determining what needs  
to be synched. It uses file based storage - depending on the Z-Push  
version it uses either a single file or a directory of files for each  
device. These files contain, along with some basic device state  
information, a list of every UID that is on the device.
+
+To determine what has changed, Z-Push essentially polls whatever  
storage backend e.g., the IMAP server, every $timeout seconds to get  
the **full** list of message IDs on the server. It then iterates over  
all the UIDs that are known to be on the device and stats every single  
one of these UIDs against the server to get the modification time,  
flags etc.
+
+Like mentioned above, a number of backends are based on this Diff  
backend. Out of the box, if you are not using a Zarafa server you have  
the following options:
+
+* An IMAP backend - obviously only for syncing emails. This uses the  
PHP IMAP functions for fetching the complete list of message IDs and  
stating each and every UID - on each and every PING loop - by default  
something like every 10 seconds or so.
+* A vCard backend that syncs contacts against a directory of vCards  
on the server.
+* A Kolab backend - I'm not sure how complete this is, but this may  
be the backend that's used by Kolab's !ActiveSync support.
+* A Maildir backend that - from what I can tell - syncs email by  
using filesystem based commands instead of going through an IMAP server.
+* A !SearchLdap backend that - from what I can tell - is used as a  
Global Address Book source for searching for individual contacts (not  
for syncing the entire address book).
+
+As of the time Horde_ActiveSync was written, you could only use  
//one// backend at a time - so, unless you were using Zarafa (or maybe  
Kolab) you could sync email //or// contacts. Since then they have  
started a "combined" backend that is supposed to wrap any number of  
backends. Last I checked it wasn't complete yet.
+
+The main differences between 1.5.x and 2 are the versions of EAS that  
are supported. 1.5.x supports only up to Exchange 2003sp1 (same as  
Horde). Version 2 is supposedly going to support up to EAS 14  
(Exchange 2010) - though I believe only up to 12.1 (Exchange 2007) is  
currently working.
+
++++The main differences
+
+Some of these are specific to using Horde data as a backend to  
Horde_ActiveSync:
+
+# Modularity. Separate classes for maintaining device state and for  
obtaining message diffs. If not using Horde as a backend, all that  
would theoretically be needed is to write a new class that extends  
Horde_ActiveSync_Driver_Base. This allows the backend, itself, to  
determine the best way to calculate diffs...like using Horde's History  
system. Support is also built in to allow using a different method of  
determining diffs based on the collection we are syncing. So, for  
example, if we ever implement email we would need a way of determining  
diffs that is not based on on the History system. This implementation  
allows us to easily add a new diff system and use multiple diff  
systems at once e.g., use History for contacts/calendar/tasks and some  
other diff system for email. In Z-Push, diff generation and state  
management are tightly coupled.
+# Efficiency. The history based diff engine is orders of magnitude  
more efficient than using Z-Push's file based diff backend.
+# Unless using Zarafa, Z-Push contained no message-specific logic.  
For example, no code for dealing with appointment related issues such  
as timezones, recurrence series etc. Horde_ActiveSync contains support  
for these things out of the box.
+# At least at the time of writing, Horde allowed better configuration  
of things such as heartbeat/timeout intervals. We also actually allow  
configuring available security policies. Z-Push had basic support for  
provisioning and for turning on or off the requirement for a device  
PIN - but contained no facility for configuring any of the other  
options.  Also, if using Horde_ActiveSync as part of a typical Horde  
install you get all the ease of configuration that our administration  
interface provides. I think some of this has improved as part of  
implementing more recent EAS versions in Z-Push.
+# I don't have hard data on device compatibility as it compares to  
Z-Push, but I do know that we have fixed some device specific issues  
in the past that - at least at the time - were not working with  
Z-Push. Certain Nokia devices come to mind that use !MfE. Z-Push lists  
these as "unknown" compatibility but they work, at least for  
contacts/calendar with Horde.
+# Horde_ActiveSync doesn't currently support email sync - where it is  
possible, albeit inefficient, to sync email using Z-Push.
+# Horde_ActiveSync currently only supports up to Exchange 2003sp1 -  
Z-Push has code in development that works to some extent with 2007 and  
plans to look at supporting up to 2010.
+# Horde_ActiveSync supports multiple users per device - when the  
device supports it. AFAIK, Z-Push only supports a single user account  
per device.

  ++ Todo

  * Implement more recent protocol version support - version 12 or  
maybe 12.1 (Exchange 2007??) should be fairly non-disruptive. Version  
12 would get us more atomic policy settings, local wipe rules, as well  
as the ability to send the policy settings to the client as the more  
compact wbxml. 14 (Exchange 2010?) would probably be lots more work as  
it does away with PING, using SYNC for waiting for changes instead.