[cvs] [Wiki] changed: Project/ActiveSync

[Michael Rubinsky]

mrubinsk  Mon, 29 Mar 2010 02:31:38 -0400

Modified page: http://wiki.horde.org/Project/ActiveSync
New Revision:  1.21
Change log:  Some notes on remote wipe/provisioning

@@ -53,19 +53,19 @@
  After the connection particulars are entered, you should choose to  
enable the folders that you want sync'd. Right now only Contacts and  
Calendar are supported.

  ++ Rough list of issues/todos/development notes in no particular order

-Horde_History state driver. Currently, !ActiveSync support uses a  
file-based state driver to persist the PIM state so we know what  
changes. This is a refactored implementation of what the Z-Push  
library does. For Horde, this is inefficient, as we have the data  
needed to know what has changed and when. Once the majority of the  
feature set is working, a Horde_History driver should be written to  
replace the file based driver when syncing contacts, calendar, and  
todo data. We might still need it if/when push email is implemented.  
The backend drivers are able to specify a particular state storage to  
enable this functionality if it is needed.
+* Horde_History state driver. Currently, !ActiveSync support uses a  
file-based state driver to persist the PIM state so we know what  
changes. This is a refactored implementation of what the Z-Push  
library does. For Horde, this is inefficient, as we have the data  
needed to know what has changed and when. Once the majority of the  
feature set is working, a Horde_History driver should be written to  
replace the file based driver when syncing contacts, calendar, and  
todo data. We might still need it if/when push email is implemented.  
The backend drivers are able to specify a particular state storage to  
enable this functionality if it is needed.

-Need to implement ghosted properties / SUPPORTED tag. Currently, each  
message that is sent from PIM -> Server is overwritten and replaced  
with only what the PIM sends. It's possible for some PIMS to ghost  
contact and calendar properties so that only the supplied tags are  
changed and missing, ghosted, properties are retained on the server.   
When a PIM supports this, it sends a SUPPORTED tag with children  
representing the NON-ghosted properties. The absence of the SUPPORTED  
tag would indicate that any property not transmitted should be handled  
as a ghosted property.
+* Need to implement ghosted properties / SUPPORTED tag. Currently,  
each message that is sent from PIM -> Server is overwritten and  
replaced with only what the PIM sends. It's possible for some PIMS to  
ghost contact and calendar properties so that only the supplied tags  
are changed and missing, ghosted, properties are retained on the  
server.  When a PIM supports this, it sends a SUPPORTED tag with  
children representing the NON-ghosted properties. The absence of the  
SUPPORTED tag would indicate that any property not transmitted should  
be handled as a ghosted property.

-Configurable heartbeat interval range: The protocol allows for  
rejecting heartbeat intervals that fall outside a specific range, and  
send back a suggested heartbeat interval to the client. This should be  
implemented as a configuration value.
+* Configurable heartbeat interval range: The protocol allows for  
rejecting heartbeat intervals that fall outside a specific range, and  
send back a suggested heartbeat interval to the client. This should be  
implemented as a configuration value.

-Support for provisioning is already implemented, but we still need to  
figure out all the possible policies available, and the values to use  
to set them etc... Once more are available, they should be added as  
configuration parameters.
+* Basic support for provisioning is already implemented, but support  
for remote wipe still needs work. The state storage needs to be able  
to support username/devid/policykey listing. The Z-Push file-based  
state storage did not support this, and actually never verified the  
policykey at all when using this state storage method. This should be  
easy to add by storing the state files under a username directory. The  
policykey storage was already added to the device's ping-state file so  
we can verify the key and enforce changes. Of course, a new  
history/sql state storage would make this easier (see first point).  
Version 12 and higher also support a "local wipe" which automatically  
wipes the device when certain policies are violated such as maximum  
password attempts (see task below regarding versions).

-Todo syncing: Neither the iPod/iPhone or Android have a native Todo  
application. !TouchDown does provide one, but backend support still  
needs to be added.
+* Todo syncing: Neither the iPod/iPhone or Android have a native Todo  
application. !TouchDown does provide one, but backend support still  
needs to be added.

-Implement more recent protocol version support - version 12 or maybe  
12.1 (Exchange 2007??) should be fairly non-disruptive. 14 (Exchange  
2010?) would probably be lots more work as it does away with PING,  
using SYNC for waiting for changes instead.
+* 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.

  ++ Resources

  http://z-push.sourceforge.net