Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CardSync Synchronization"
(New page: =Transfer objects= Image:CardSync_Synchronization_TOs.png ==CommandTO== Command transfer object. Encapsulate commands in transfer objects. Please, see "Command" design pattern. * Str...) |
|||
| Line 1: | Line 1: | ||
| + | = Problems = | ||
| + | There are few situations when client should synchronize local icard store with server: | ||
| + | * client app worked off-line and user made some changes (for example, user could update p-cards traveling by plane), so client has list of changes (array of CommandTO) which should be passed to server; | ||
| + | * client app determinate that client RootRevision less then server RootRevision ( for example, user could use client app on other device(laptop/iphone/etc) ), so client app should load changes from server. | ||
| + | |||
| + | = Strategy = | ||
| + | <ol> | ||
| + | <li> Client app should compare local RootRevision with server RootRevision. If they're not equals, i.e. client RootRevision may less than server, that client must load changes from server. | ||
| + | <li> Only after loading changes from server, and If client app has list of local changes, client should upload them to server. | ||
| + | </ol> | ||
| + | |||
=Transfer objects= | =Transfer objects= | ||
[[Image:CardSync_Synchronization_TOs.png]] | [[Image:CardSync_Synchronization_TOs.png]] | ||
| Line 5: | Line 16: | ||
Command transfer object. Encapsulate commands in transfer objects. Please, see "Command" design pattern. | Command transfer object. Encapsulate commands in transfer objects. Please, see "Command" design pattern. | ||
| − | * String id - Represents command id, Client should use it it for processing command executed status @see CmdExecStatusTO. | + | * String id - Represents command id, Client should use it it for processing command executed status @see CmdExecStatusTO. |
| − | * String name - Represents operation/command name. It must be one of the following constants: | + | * String name - Represents operation/command name. It must be one of the following constants:Add/Update/Delete. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
* String resourceType - Represents resource type. It might be "PCard","MCard","CardHistory","UserProfile" etc. | * String resourceType - Represents resource type. It might be "PCard","MCard","CardHistory","UserProfile" etc. | ||
* String resourceId - Represents server resource identifier. @see BaseTO#id | * String resourceId - Represents server resource identifier. @see BaseTO#id | ||
* BaseTO resource - Represents resource. | * BaseTO resource - Represents resource. | ||
| + | ==CmdExecStatusTO== | ||
| + | Represents command executed status TO. | ||
| + | |||
| + | * String commandId - Represents command id. @see CommandTO#id | ||
| + | * String statusCode - Represent status code of executed command on server. It may be '0' or error code. | ||
| + | * String statusMessage - Represent status message of executed command on server. it may be used for returning error message. | ||
=From server to client= | =From server to client= | ||
| + | Client have to load changes from server passing client "RootRevision" by using: | ||
| + | * REST - GET /CommandLog request; | ||
| + | * JAX-WS - getCommandLog request. | ||
| + | |||
| + | These methods return array of CommandTO, which client have to process. | ||
| + | |||
=From client to server= | =From client to server= | ||
| − | = | + | Client have to upload local changes to server by using: |
| + | * Rest - PUT /CommandLog request; | ||
| + | * JAX-WS - execCommands request. | ||
| + | |||
| + | These methods return array of CmdExecStatusTO. Client have to check CmdExecStatusTO.statusCode. if CmdExecStatusTO.statusCode is not "0" (server couldn't apply changes), client should update resource from server and reject local changes or ask user about. | ||
| + | |||
| + | =Problems= | ||
Revision as of 07:02, 10 July 2009
Contents
Problems
There are few situations when client should synchronize local icard store with server:
- client app worked off-line and user made some changes (for example, user could update p-cards traveling by plane), so client has list of changes (array of CommandTO) which should be passed to server;
- client app determinate that client RootRevision less then server RootRevision ( for example, user could use client app on other device(laptop/iphone/etc) ), so client app should load changes from server.
Strategy
- Client app should compare local RootRevision with server RootRevision. If they're not equals, i.e. client RootRevision may less than server, that client must load changes from server.
- Only after loading changes from server, and If client app has list of local changes, client should upload them to server.
Transfer objects
CommandTO
Command transfer object. Encapsulate commands in transfer objects. Please, see "Command" design pattern.
* String id - Represents command id, Client should use it it for processing command executed status @see CmdExecStatusTO. * String name - Represents operation/command name. It must be one of the following constants:Add/Update/Delete. * String resourceType - Represents resource type. It might be "PCard","MCard","CardHistory","UserProfile" etc. * String resourceId - Represents server resource identifier. @see BaseTO#id * BaseTO resource - Represents resource.
CmdExecStatusTO
Represents command executed status TO.
* String commandId - Represents command id. @see CommandTO#id * String statusCode - Represent status code of executed command on server. It may be '0' or error code. * String statusMessage - Represent status message of executed command on server. it may be used for returning error message.
From server to client
Client have to load changes from server passing client "RootRevision" by using:
- REST - GET /CommandLog request;
- JAX-WS - getCommandLog request.
These methods return array of CommandTO, which client have to process.
From client to server
Client have to upload local changes to server by using:
- Rest - PUT /CommandLog request;
- JAX-WS - execCommands request.
These methods return array of CmdExecStatusTO. Client have to check CmdExecStatusTO.statusCode. if CmdExecStatusTO.statusCode is not "0" (server couldn't apply changes), client should update resource from server and reject local changes or ask user about.