|
Requests
Objects
Enums
|
SynchronizationThe syncrhonization api is token based. On first syncrhonization you do not specify a sync token, and you get a all objects and new token in the response. When you have proccessed the objects you should call a SyncCommit to confirm the changes has been made in the client. If you do not make any changes you can pass the JSTaskSynchronization unmodified back to SyncCommit. If you do have changes you can modify the objects and the changes will be saved. If you for some reason have objects you could not process these should not be send back to SyncCommit. This Sync and SyncCommit handshake makes it possible for the MeetingBooster to keep trak of changes for individual synchronizations, allowing each user to have more than one synchronization. On the next sync request you use the previous token, and you will only get new, modified and deleted objects since the last sync. Each time you will get a new token and you use that token on you next sync request. You can syncrhonize meetings and tasks with MeetingBooster. The synchronization is user based - you synchronize your own meetings or tasks. For meeting synchronization see Sync and SyncCommit For task synchronization see Sync and SyncCommit Calendar entriesThe calendar in MeetingBooster is only used for conflict checking. Each entry has a start and end to specify a timeslot where you are not availble. The calendar is not synchronized from MeetingBooster to the client, only from the client to MeetingBooster using the SyncCommit requests. When deleting if you only specify a ClindSyncId, and it cannot be found in the calendar, MeetingBooster will search for a Meeting with the ClientSyncId and delete it if found. This can be used if the client has a deleted Calendar entry but does not know if it was actually a MeetingBooster meeting. Sync objectsThe JSSyncObject is the base for all sync objects. The ClientSyncId property is a string the client can asing to anything unique - like a guid. The client can use this to identify the object client side, and MeetingBooter can use it to find it server side if no id is specified. If you are modifying an object client side and the object has already been synchronized to MeetingBooster, and you do not know the MeetingBooster id of the object, MeetingBooster will use the ClientSyncId to find the object. E.g. You create a new task client side and send it to MeetingBooster using SyncCommit. Later when you want to change it and you do not have the MeetingBooster id you can do so by only specifying the ClientSyncId. This makes it possible to make a syncrhonization wihout the need to keep a relationship client side of the MeetingBooster id and the ClientSyncId |