-
Notifications
You must be signed in to change notification settings - Fork 10
syncEngine3.x
- Runs in the background as a separate service
- Communicates with endpoints via connectors
- Currently have a read-only-file connector and a bedework over CalWS-SOAP connector
The sync engine maintains a list of subscriptions. A subscription is a connection between two points A and B and may be a one way subscription (either way) or a 2 way (not implemented). At the moment end A is always bedework and end B is probably an ics file or something that looks like one.
Subscriptions are polling or not. For polling the sync engine periodically checks the end point for changes - usually using an etag as a test. Non-polling subscriptions are not in use but the assumtion is that the end point informs the system somehow that a change has taken place. Exchange for instance is able to do this.
A number of properties control the poll rate. There is a minimum poll rate and teh end point may set a poll rate when creating the subscription.
A keystore location can be supplied. This setting is used to set the system property "javax.net.ssl.trustStore". I think this is only needed for non-standard certs as java has the standard certs already configured in to the runtime.
Subscriptions are created using the folder and collection management UI. Most of the interactions are handled by the calsvc Synch class. A subscription message is sent to the sync engine defining the local (bedework) end point, the remote end point and refresh rate.
periodically the file will be checked and, if nay changes have taken place, the sync engine will connect to bedework via the special service connection - switch to act as the subscribing principal - and update the local calendar collection.
On start up - with debug enabled - the sync engine will emit information about the current state. This includes information about each subscription and its current state. This is probably unworkable on a production system which could have very many subscriptions.