CN1794724A - Method of realizing data synchronization on SyncML layer - Google Patents

Abstract

The invention discloses a method for realizing data synchronization at the SyncML layer, which not only provides a detailed implementation method for realizing data classification synchronization, so that synchronization for a certain directory can be realized, but also in the process of specific implementation , trying to transmit information such as number and data type, avoiding too much specific data content to be transmitted, and the actual physical space occupied by the synchronization data is also small (only one copy of each data), thus minimizing redundancy The existence of data saves limited equipment resources and network resources. At the same time, users can create physical or logical categories according to their own wishes, and can specify any directory or category for synchronization, which enhances the user experience.

Description

The Method of Realizing Data Synchronization in SyncML Layer

technical field

The invention relates to the technical field of data synchronization specification (SyncML Data Synchronization) defined by the Open Mobile Alliance, in particular to a method for realizing data synchronization at the SyncML layer.

Background technique

IBM, Nokia, Palm, Psion and other companies created the industry group SyncML initiative in February 2000 in order to formulate standard specifications that can synchronize personal information and enterprise data between multiple platforms and networks. The purpose of developing SyncML is to enable end users, equipment developers, infrastructure developers, data providers, application software developers, and service providers to work together, so that any terminal device can be used to access any network data anytime, anywhere. A typical application of SyncML data synchronization is data synchronization between mobile devices or application servers, and network servers. In addition, SyncML can also be used for peer-to-peer data synchronization, such as between two PCs.

Figure 1 shows a schematic diagram for realizing synchronization. After the SyncML client and server negotiate parameters in the synchronization initialization phase, the terminal and the server send each other changed data to ensure data synchronization between the two parties.

Synchronization client (DS Client), which is usually a smart terminal such as PC software, mobile phone or PDA. DS Client includes a client database (Client Database), which is used to store the data required by the user, which includes: address book, schedule, note, SMS, email, etc. These data have standard specifications to define their format. The client can convert the data into a standard format and send it to the server. After the server processes it, it can save it in its own database.

The synchronization server (DS Server) can receive data synchronization messages and synchronization commands from the DS Client, and can send synchronization messages to the synchronization client. This device can be a web server or a PC. DS Server includes a server-side database (Server Database), which is used to store data on the server.

Both the client and the server store an identifier for identifying data. The client uses LUID (Local Unique Identifier) as the data identifier; the server uses GUID (Global Unique Identifer) as the data identifier.

Referring to FIG. 2, FIG. 2 shows a schematic diagram of data storage at the client and server. On the client side, it is only necessary to maintain the corresponding relationship between LUID and specific actual data. On the server side, not only the corresponding relationship between GUID and specific actual data needs to be maintained, but also the corresponding relationship between GUID and LUID.

There are many types of synchronization, see Table 1 for details. Synchronization type Description Two-way synchronization (Two-waysync) Two-way synchronization is a commonly used synchronization method. In this manner, the synchronization client and the server only exchange data modification information in each other's devices (unmodified data are not exchanged). The client first sends its modification information. Slow sync Slow synchronization is a special type of two-way synchronization. The difference is that data must be compared item by item and field by field. This means that when synchronizing, both the client and the server must send all the data in the local database to the peer, and then the server or the client performs a field-by-field comparison of each piece of data received and each piece of data saved by itself. Simultaneous analysis. One-way sync from client only Client-side one-way synchronization is a one-way synchronization. Only the client sends its data modification information to the server, and the server does not send the modification information of the server to the client. Client Refresh (Refresh sync from client only) Client refresh is also a one-sided synchronization. The client sends all the data in the local database to the server, and the server overwrites all the data in the server database with the data from the client. That is, the data in the server is exactly the same as that in the client, with no more, no less, and no different records. One-way sync from server only Server-side one-way synchronization is similar to client-side one-way synchronization. Only the server sends its data modification information to the client, and the client does not send its modification information to the server. Refresh sync from server only Server-side refresh is similar to client-side refresh. The server sends all the data of the user in the database to the user client, and the client uses the data from the server to cover all the data in the client database. That is, the data in the client is exactly the same as that in the server, with no more, no less, and no different records. Server AlertedSync (Server AlertedSync) Server-side notification synchronization means that the server first reminds the client to perform a synchronization operation. That is, it is up to the server to tell the client to start a specific type of synchronization operation. It is just that the server notifies the terminal and requires it to initiate some kind of synchronization, and the subsequent synchronization process may be the above six synchronization methods.

Table 1

The synchronization process specified in the SyncML specification is usually divided into three stages:

1. In the synchronization initialization phase, it mainly completes identity authentication, negotiation of databases that need to be synchronized, and negotiation of synchronization capabilities (which data is supported for synchronization, which synchronization types are supported, etc.). This interactive process may need to continue several times to complete.

2. Synchronization stage, which is mainly used for one end of the client and the server. According to the state of the data, the changed data is sent to the other end of the client and the server through operation commands, and the other end performs the same operation according to these commands. operation to achieve the purpose of synchronization.

3. The synchronization completion stage is mainly used for the client and the server to confirm the synchronization completion.

In the prior art, two formats of Folder and File are defined for actual data, which mainly simulate the tree-like directory structure of folders and files on the PC, and define that Folder and File have attributes similar to the file system, such as Whether it is hidden (h), whether it is a system directory or file (s), whether it is compressed (a), whether it is deleted, if it is deleted, the directory or file can be deleted (d), whether it is writable (w), whether it is readable (r), whether the file is executable (x), etc. Moreover, when performing a synchronization operation, it can only be used to synchronize the directory structure in a physical way like a file system.

At the same time, a filtering (Filtering) function is also provided in the prior art, and its function is mainly to specify filtering conditions in the initialization negotiation phase. For example: when negotiating terminal capabilities, filter conditions can be specified for the data to be synchronized, such as:

A. Specify that the client does not receive the PHOTO attribute in the vCard;

B. Specify the client to only synchronize contacts belonging to the Business and Personal groups;

The filter condition B can be regarded as a process in which the client and the server negotiate to synchronize only the specified directory.

However, even for the directory structure of a physical method used to synchronize file systems, the specific implementation method is not clearly stated in the existing specifications, that is, how to use Folder and File for recursive synchronization is not clear. Therefore, currently, almost all manufacturers There is no implementation method for synchronizing a certain directory.

Furthermore, even if this method is adopted, it can only realize the synchronization of the directory structure in the physical mode, but cannot realize the synchronization of the directory structure in the logical mode, and it is impossible to distinguish between recursive synchronization and non-recursive synchronization. For example, assuming that there are several physically existing directory structures such as address book, short message, and e-mail in the user's mobile phone, in the prior art, the user can only synchronize short messages, but cannot store stored short messages. It is divided into two logical categories of "joke" and "blessing", and it is not possible to only synchronize the logical category of "joke". At the same time, it does not support a data item to exist in two categories at the same time. For example, for the user address book, the requirement that Zhang San belongs to both the "colleague group" and the "friend group" cannot be realized.

In addition, there is a group attribute in the existing address book (vCard) specification, which can be used for classification, but it is bound to specific synchronization content, that is, the directory specified for synchronization depends on the specific data format, and the same content can only belong to one classification It cannot belong to multiple categories at the same time. For example, the attribute of Zhang San in the address book is "colleague", so he can only belong to the category of "colleague", and cannot belong to the category of "friend". And other data formats, such as text messages, schedules, etc., do not support group-based attributes. It can be seen that this classification is not universal. Furthermore, the group attribute based on vCard requires the user to open a specific data format to edit the group name, which may cause "friends" and "friends" to be considered as different groups due to misoperation, and are case-sensitive. Moreover, the group attribute can only support one-level directory structure, and does not support multi-level directories.

In the prior art, when the client operation and the server operation conflict, only a simple solution based on client data or server data is adopted; after the directory structure is adopted, the conflict occurs It will become complicated, for example: the user moves the A directory on the client to make it a subdirectory of the B directory, and the server adds an entry in the A directory, and the operations of the two conflict, if the existing technology is adopted In the end, it can only be the operation of the client, and the new entry on the server is discarded; or an entry is added to the A directory on the client, and the operation of moving the A directory to the B directory is discarded; the actual situation that the user wants is the A directory A new entry is added under , and the A directory is moved to the B directory.

Contents of the invention

In view of this, the purpose of the present invention is to provide a method for realizing data synchronization at the SyncML layer, which can specify any directory for synchronization, which not only saves network resources, but also enhances user experience.

In order to achieve the above object, technical solution of the present invention is achieved in that way:

A method for realizing data synchronization at the SyncML layer, when one of the SyncML client or the server receives a synchronization request from the user, the client and the server negotiate the directory to which the data to be synchronized belongs; the method comprises the following steps:

a. One of the SyncML client or server first determines the type of data to be synchronized in the received request synchronization command, if it is a directory item, then perform step b, if it is a data item, then perform step c;

b. Obtain the current state of the data to be synchronized from the set directory table. If the current state indicates no change, do not process it. If the current state indicates change, construct the corresponding data according to the change state A synchronization command, sending the data synchronization command to the client or the other end of the server;

c. Obtain the change state of the data to be synchronized from the set data entry-directory correspondence table, and construct a corresponding data synchronization command according to the change state, and send the data synchronization command to the client or server the other end of the

The constructed command includes at least the data type of the data to be synchronized and the serial number of the data to be synchronized;

After the other end of the SyncML client or server receives the synchronization command from the opposite end, it performs the following steps:

d. According to the received data synchronization command, determine the operation type, change the content of the corresponding table, and realize data synchronization.

Preferably, the one that initiates the synchronization request is the client, and the one that executes the synchronization operation is the server;

The change state of the data to be synchronized is newly added N, and the data synchronization command corresponding to the change state is an ADD synchronization command; the number of the data to be synchronized in the order is the number of the data at the client, And the command further includes: the specific data to be synchronized and the parent directory to which the data belongs;

The server side determines that the operation type is to increase; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

According to the received data synchronization command, save the received data to be synchronized in the local database, assign the local number of the server to the data to be synchronized, and save it in the corresponding relationship list between the number in the SyncML client and the number in the server that has been set The corresponding relationship between the number of the synchronization data on the client side and the number of the synchronization data on the server side; and, according to the data type of the data to be synchronized in the synchronization command, determine the type of the synchronization data, if the data type is a directory entry, then locally A corresponding entry is added to the set directory table, and if the data type is a data item, a corresponding entry is added to the locally set data entry table and data entry-directory correspondence index table.

Preferably, the one that initiates the synchronization request is the server, and the one that executes the synchronization operation is the client;

The change state of the data to be synchronized is new N, and the data synchronization command corresponding to the change state is an ADD synchronization command; the number of the data to be synchronized in the order is the number of the data on the server side, And the command further includes: the specific data to be synchronized and the parent directory to which the data belongs;

The client determines that the operation type is to increase; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

According to the received data synchronization command, save the received data to be synchronized in the local database, assign the local number of the client to the data to be synchronized, and determine the type of the synchronized data according to the data type of the data to be synchronized in the synchronization command , if the data type is a directory item, add the corresponding entry in the locally set directory table, if the data type is a data item, add the corresponding entry in the locally set data entry table and data entry-directory correspondence index table ; Afterwards, return the corresponding relationship between the serial number in the data client and the serial number in the server to the server end, and store the received corresponding relationship in the locally configured SyncML client serial number and the serial number in the server Correspondence list.

Preferably, after step b is executed, it further includes: e judging whether there is a newly added data item under the newly added directory item, and if so, repeating step c until all data items are fully synchronized, and then executing Step f; if not, then directly execute step f;

f. Determine whether there is a newly added subdirectory item under the newly added directory item, if yes, repeat step b until all directory items are fully synchronized, then perform step e, if not, then end.

Preferably, after step b is executed, the method further includes: e judging whether there is a newly added data item under the newly added directory item, and if so, repeating step c until all data items are synchronized.

Preferably, the change state of the data to be synchronized is update U, and the data synchronization command corresponding to the change state is a Replace synchronization command, and the command further includes: the specific data to be synchronized, and the The parent directory to which the data belongs;

The other end determines that the operation type is update; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

According to the received data synchronization command, determine the type of the synchronization data, if the data type is a directory item, update the entry corresponding to the local number of the data to be synchronized in the local directory table, if the data type is a data item , update the entry corresponding to the local number of the data to be synchronized in the locally set data entry table.

Preferably, after step b is executed, it further includes: g judging whether there is an updated data item under the updated directory item, and if so, repeating step c until all data items are fully synchronized, and then performing step h; if not, execute step h directly;

h. Determine whether there is an updated sub-directory item under the updated directory item, if yes, repeat step b until all directory items are synchronized, then perform step g, if not, then end.

Preferably, after step b is executed, the method further includes: g judging whether there is an updated data item under the updated directory item, and if so, repeating step c until all data items are synchronized.

Preferably, the change state of the data to be synchronized is moving M, and the data synchronization command corresponding to the change state is a Move synchronization command; and the command further includes: the parent directory to which the changed data belongs ;

The other end determines that the operation type is mobile; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

According to the received data synchronization command, determine the type of the synchronization data, if the data type is a directory entry, change the parent directory of the entry corresponding to the local number of the data to be synchronized to receive in the directory table that has been set locally If the data type is a data item, change the parent directory of the entry corresponding to the local number of the data to be synchronized to the received one in the locally set data entry-directory correspondence table. Synchronize the parent directory in the command.

Preferably, the current state indicated in step b is delete D, and the data synchronization command corresponding to the changed state is a delete Delete synchronization command; then the end that initiates the synchronization request further includes: judging the Whether the data items in the data items and the data items in the subdirectories of the directory only exist in the directory to be deleted, if yes, construct a delete command, and the delete command contains information indicating permanent deletion; otherwise, for each data The project and the directory item respectively construct a delete command, and only exist in the data item in the directory to be deleted or the delete command corresponding to the directory item contains information indicating permanent deletion, not only in the data item in the directory to be deleted or the deletion command corresponding to the directory entry contains information indicating non-permanent deletion;

The other end determines that the operation type is deletion; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

Determine the deletion type and the data type of the data to be synchronized according to the received data synchronization command. If the data type is a directory item, whether the deletion type is permanent deletion or non-permanent deletion, it will be deleted in the locally set directory table. Synchronize the entry corresponding to the local number of the data; if the data type is a data item, and the deletion type is permanent deletion, delete the data in the local database, and set the data entry table and data entry-directory correspondence in the local In the table, delete the entries corresponding to the local numbers of the data to be synchronized; if the data type is a data item, and the deletion type is non-permanent deletion, delete the data to be synchronized locally in the local data entry-directory correspondence table The entry corresponding to the number of .

Preferably, the current state indicated in step b is delete D, and the data synchronization command corresponding to the changed state is a delete Delete synchronization command;

The other end determines that the operation type is deletion; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

Determine the type of deletion and the data type of the data to be synchronized according to the received data synchronization command. If the data type is a directory item, then judge the data item under the directory to be deleted, the subdirectory of the directory and the data item under the subdirectory Whether it only exists under the directory to be deleted, if yes, then determine that the directory to be deleted and the data items under the directory, and the subdirectory and the data items under the subdirectory are permanently deleted, otherwise, determine the directory to be deleted and the data items under the subdirectory Data items or directory items that only exist in the directory to be deleted are permanently deleted, and data items or directory items that do not only exist in the directory to be deleted are not permanently deleted;

If the deletion is a directory item, no matter whether the deletion type is permanent deletion or non-permanent deletion, the entry corresponding to the local number of the data to be synchronized will be deleted in the locally set directory table; if the deletion is a data item, and If the deletion type is permanent deletion, delete the data in the local database, and delete the entry corresponding to the local number of the data to be synchronized in the local data entry table and data entry-directory correspondence table; if the data If the type is a data item, and the deletion type is non-permanent deletion, delete the entry corresponding to the local number of the data to be synchronized in the local data entry-directory correspondence table.

Preferably, the change state in step c is delete D, and the data synchronization command corresponding to the change state is a delete delete synchronization command; then the end that initiates the synchronization request further includes: judging the received Whether to indicate that the data item is permanently deleted in the delete command, if yes, further include the mark of permanent deletion in the delete command, otherwise, determine whether the data item to be deleted is located in multiple directories, if so, in the delete command further includes an identifier of non-permanent deletion, otherwise the deletion command further includes an identifier of permanent deletion;

The other end determines that the operation type is deletion; the process of changing the content of the corresponding table and realizing data synchronization includes the following steps:

After the data type is determined to be a data item according to the received data synchronization command, then the deletion type is determined. If the deletion type is permanent deletion, the data is deleted in the local database, and the data entry table and data entry-directory that have been set locally In the correspondence table, delete the entries corresponding to the local numbers of the data to be synchronized; if the deletion type is non-permanent deletion, delete the corresponding entries in the local data entry-directory correspondence table. entry.

Preferably, after the other end of the client or server performing the synchronization operation completes the delete synchronization operation, it further includes: the end that initiates the synchronization request deletes the corresponding data item in the corresponding data table that has been set locally.

Preferably, if the client that initiates the synchronization request and the server that performs the synchronization operation, the number of the data to be synchronized in the synchronization command is the number of the data on the client; the server receives the data synchronization After the command, before determining the data type, it further includes: obtaining the local number of the updated data to be synchronized on the server from the set correspondence list between the number in the SyncML client and the number in the server, and then continue to perform subsequent operations.

If the one that initiates the synchronization request is the server, and the one that executes the synchronization operation is the client, then the number of data to be synchronized in the synchronization command is the correspondence between the number in the client and the number in the server that the server has set according to itself. The number of the data obtained by the relationship list on the client side.

Preferably, the directory tables respectively set in the SyncML client and the server include at least the directory item number, the directory name, the parent directory to which the directory item name belongs, and the corresponding relationship of the directory item status;

The data entry-directory correspondence index tables respectively set in the SyncML client and server include at least the correspondence between data item numbers, parent directories, and data item states.

Preferably, the data entry tables respectively set in the SyncML client and the server at least include: the corresponding relationship between the data item number and the specific data content;

The list of correspondences between numbers in the SyncML client and numbers in the server that has been set on the server side at least includes: a correspondence between numbers in the client and numbers in the server.

Preferably, the operation of negotiating the directory of the data to be synchronized includes the following steps in the initial stage: predefining the format of the URI, and specifying the directory to be synchronized by the meaning of the URI in the target database element.

Preferably, the operation of negotiating the directory to which the data to be synchronized belongs is at the initialization stage, including the following steps: specifying the directory to be synchronized by the filter condition in the filter condition element.

Preferably, the method further includes: adding an arbitration result that is processed by combining the server and the client (Win-Win);

When the modification operations of the server and the client conflict, the client executes the synchronization operation according to the modification of the server, and the server executes the synchronization operation according to the modification of the client;

The modification includes adding, updating, moving, deleting and copying operations.

The method of the present invention not only provides a specific implementation method for realizing data classification synchronization in detail, so that synchronization for a certain directory can be realized, but also, in the process of specific implementation, try to transmit information such as numbering and data types, It avoids the transmission of too much specific data content, and the actual physical space occupied by the synchronous data is also small (only one copy of each data), thus minimizing the existence of redundant data and saving limited device resources and network resources. At the same time, users can create physical or logical classifications according to their own wishes, and can put data items into specified directories through drag and drop operations, without manual editing of data items; any directory can be designated for recursive or non-recursive synchronization. Enhanced user experience.

Description of drawings

Figure 1 shows a schematic diagram for realizing synchronization;

Fig. 2 shows the data storage of the client and the server;

FIG. 3a is a schematic diagram of a user-defined data structure applying Embodiment 1 of the present invention;

FIG. 3b is a schematic diagram of data storage of a client applying Embodiment 1 of the present invention;

FIG. 4a is a schematic diagram of a user-defined data structure applying Embodiment 2 of the present invention;

FIG. 4b is a schematic diagram of data storage of a client applying Embodiment 2 of the present invention;

FIG. 5a is a schematic diagram of a user-defined data structure applying Embodiment 3 of the present invention;

FIG. 5b is a schematic diagram of data storage of a client applying Embodiment 3 of the present invention;

FIG. 6a is a schematic diagram of a user-defined data structure applying Embodiment 4 of the present invention;

FIG. 6b is a schematic diagram of data storage of a client applying Embodiment 4 of the present invention;

FIG. 7a is a schematic diagram of a user-defined data structure applying Embodiment 5 of the present invention;

FIG. 7b is a schematic diagram of data storage of a client applying Embodiment 5 of the present invention;

FIG. 8a is a schematic diagram of a user-defined data structure applying Embodiment 6 of the present invention;

FIG. 8b is a schematic diagram of data storage of a client applying Embodiment 6 of the present invention.

Detailed ways

The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

In order to enable users to create physical or logical categories according to their own wishes, and specify any category for recursive synchronization or non-recursive synchronization, the following three data tables need to be set on the client and server:

1. Data Item Table (Data Item Table): This table is used to save all data item information, which includes the corresponding relationship between the data item number and the specific data content (Data); wherein, the data item number starts with Item LUID is represented by Item GUID on the server side

2. Folder Table: This table is used to save all directory item information, including the directory item number, directory name (Name), the parent directory (Parent Source) to which the directory item name belongs, and the status of the directory item (Folder Satus) correspondence. The states mainly include Existing (E), New (N), Update (U), Delete (D), Move (M) and Copy (C). Among them, Delete can It is divided into two states: Delete permanently (P-D) and Delete non-permanetly (P-ND). The directory entry number is represented by Folder LUID on the client side and Folder GUID on the server side.

3. Data entry-directory correspondence index table (Index Table): This table is used to save the attribution relationship of data items, which includes the corresponding relationship between data item number, parent directory (Parent Source) and data item status (Data Satus); Wherein the data item number is represented by ItemLUD on the client side, and by Item GUID on the server side.

Furthermore, the server side also needs to save the corresponding relationship list between the serial number of the data in the SyncML client and the serial number in the server, that is, the corresponding relationship between GUID and LUID.

As we all know, synchronization in SyncML is divided into three phases: synchronization initialization phase, synchronization phase and synchronization completion phase. The processing of the synchronization completion stage in the present invention is the same as the existing method, so only the synchronization initialization stage and the synchronization stage will be described below.

In the synchronization initialization phase, in addition to negotiating the database and terminal capabilities that need to be synchronized as in the prior art, it is also necessary to specify the directory to be synchronized. Specifically, the following two ways can be implemented:

Method 1: Indicate the directory to be synchronized in the target database element. Specifically: pre-define the format of Uniform Resource Identifier (URI, Uniform Resource Identifier), pre-designate which level identifies the database address, which level represents the address of the directory, and indicate the directory to be synchronized through the URI identification. Of course, if you need to synchronize multiple directories, you can specify multiple URIs at the same time.

Method 2: Indicate the directory to be synchronized in the filter condition element. Specifically: expand the existing filtering function, and specify the directory to be synchronized in the filtering condition (such as Filter). The directory to be synchronized is a SyncML-level directory, which does not depend on the type of synchronization data. Of course, if multiple directories need to be synchronized, multiple directories can be indicated at the same time.

The synchronization phase will be described below in combination with specific embodiments. Since the client-initiated synchronization process is similar to the server-initiated synchronization process, the following only uses the client-initiated synchronization and the server-side data synchronization operation as an example for illustration.

Embodiment 1: The user adds a new directory "bless" under the root directory (./sms) of the short message, and adds two subdirectories under the "bless" directory, namely "Spring Festival" and "Mid- "autumn Festival", at the same time, add a piece of data under each directory, that is, add data N1 under the "bless" directory, add data N2 under the "Spring Festival" directory, and add data N2 under the "Mid-autumn Festival" directory Added data N3.

Referring to Fig. 3a and Fig. 3b, Fig. 3a shows a schematic diagram of a user-defined data structure applying Embodiment 1 of the present invention, wherein, a square box represents a Folder, and a circle represents a data Item; the state represented by a solid line is Existing, and the state represented by a dotted line for New. Fig. 3b is a schematic diagram of data storage of a client applying Embodiment 1 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The states of the added data in each list are correspondingly reflected in Fig. 3b.

When a user asks to sync the "bless" directory, the client generates the following sync commands sequentially:

First, after the client determines that the synchronization data is a directory item according to the command received from the user to synchronize the bless directory, it determines the status of the bless from the Folder Table as N, and then constructs an increase (ADD) synchronization command, and, in The Meta field in the constructed command indicates that the data type determined according to the Folder Table is the directory item Folder, the LUID field indicates the number 1006 of the data to be synchronized, the Data field indicates that the specific data is bless, and the SourceParent field indicates that its parent directory is the root directory .

After that, the client determines the status of the data item in the bless directory. Since the status corresponding to the data item 2001 in the Index Table is N, the ADD synchronization command is constructed, and the specific data content corresponding to 2001 is determined from the DataItem Table as N1 Finally, the Meta field in the constructed ADD synchronization command indicates that the data type is the data item Item, the LUID field indicates that the number of the data to be synchronized is 2001, the Data field indicates that the specific data is N1, and the SourceParent field indicates that its parent directory is 1006 .

Afterwards, when the client determines that there is no newly added data item in the bless directory, it will index the status of the subdirectories under the bless directory. The specific method is the same as the method for determining the bless directory, and will not be repeated here. The determined result is to build two ADD synchronization commands. The Meta field in one of the commands indicates that the data type is the directory item Folder, the LUID field indicates the number 1007 of the data to be synchronized, the Data field indicates that the specific data is Spring Festival, and the SourceParent field indicates The parent directory to which it belongs is 1006; the Meta field in another command indicates that the data type is the directory item Folder, the LUID field indicates the number 1008 of the data to be synchronized, the Data field indicates that the specific data is Mid-autumnFestival, and the SourceParent field indicates its parent directory for 1006.

Afterwards, when the client confirms that there are no newly added subdirectories under the bless directory, then determine the status of the data items under the SpringFestival directory and the Mid-autumn Festival directory. The specific method is the same as the method for determining N1. Construct two ADD synchronous commands, which will not be repeated here.

By analogy, until the ADD synchronization command is issued for all the added data, the recursive synchronization is realized in this way. Of course, if only a certain directory item is synchronized, and the data items under this directory item are no longer synchronized, the non-recursive synchronization is actually realized. In addition, it is also possible to only synchronize a certain directory item and the data items under the directory item without synchronizing the subdirectory items under the directory item.

Afterwards, all the constructed ADD synchronization commands are sent to the server. If the amount of data in each ADD command is small, multiple ADD commands can be included in one message, and one-time interaction is enough; if there is a large amount of data, multiple interactions are required. In practical applications, only one ADD synchronization command can be sent, but multiple directories and data items are included in one ADD command, that is, it is still multiple ADD commands logically.

The following describes the process of performing a synchronization operation after the server receives the above-mentioned ADD command. The table involved in this process is similar to the table shown in Figure 3b, so it is not shown in the figure.

When the server receives the synchronization command to add the bless directory item, it determines the type of the data to be synchronized as a directory item through the Meta field in the received synchronization command, and determines the serial number of the data to be synchronized on the client side as 1006 according to the LUID field. The Data field determines its name as bless, and its parent directory is determined as the root directory according to the SourceParent field. Afterwards, assign the local number Folder GUID of the server to the data to be synchronized, such as 100006. Then, add a corresponding entry in the locally set directory table, that is, add 100006, bless, the root directory, and the corresponding relationship entry of the current state of the bless data. And, keep the corresponding relationship between the number LUID of the synchronization data on the client side and the number GUID of the synchronization data on the server side in the corresponding relationship list between the number in the SyncML client and the number in the server that you have set, that is, save 1006 and 100006 Correspondence between.

When the server receives the synchronization command to add the N1 data item, it determines the type of the data to be synchronized as a data item through the Meta field in the received synchronization command, and determines the serial number of the data to be synchronized on the client side as 2001 according to the LUID field. The specific data content determined by the Data field is N1, and its parent directory is determined as 1006 according to the SourceParent field. After that, save the N1 data in the local database, and then assign the server local number FolderGUID to the data to be synchronized, such as 200001, and add the corresponding entry in the Data Item Table that has been set locally, that is, increase the correspondence between 200001 and N1 Relationship entry; add corresponding entries in the Index Table, that is, add 200001, 100006 and the corresponding relationship entries of the current state of the N1 data, and keep the corresponding relationship list between the number in the SyncML client and the number in the server that you have set. The corresponding relationship between the serial number of the synchronization data on the client side and the serial number of the synchronization data on the server side is to store the corresponding relationship between 2001 and 200001.

The method of adding Spring Festival directory items and Mid-autumn Festival directory items on the server side is the same as that of adding bless directory items, and the method of adding N2 and N3 data items is the same as that of adding N1 data items, so I won’t repeat them here.

In addition, one thing that needs to be explained is: if the server initiates a synchronization request and the client performs the synchronization operation, the synchronization request sent from the server to the client includes the number of the data to be synchronized on the server. After the client completes the synchronization operation , will return to the server the corresponding relationship between the serial number in the client and the serial number in the server, that is, the corresponding relationship between LUID and GUID, and the server will save the received corresponding relationship in the locally configured serial number in the SyncML client In the list of correspondences with numbers in the server.

So far, the synchronization operation of adding data has been realized, and the data can be a specific data item, or a directory item created according to the user's wishes, and the directory item is not limited by the physical data structure of the system. It can be seen that the advantage of applying the present invention is that only one copy of the same data needs to be transmitted, and only one copy of the same data needs to be saved at the end performing the synchronization operation, which greatly saves network resources and resources of the device itself. For example, assuming that N1 belongs to the bless, Spring Festival and Mid-autumn Festival directories at the same time, then during the synchronization operation on the server side, only two more corresponding entries need to be added in the Index Table, that is, adding 200001, 100007 and the current N1 data The corresponding relationship entry of the state and the corresponding relationship entry of 200001, 100008 and the current state of the N1 data are sufficient.

Embodiment 2: The user updates the attribute of the directory "bless" under the root directory (./sms) of the short message, and updates the data U1 under the "bless" directory, and only updates the data U2 under the "Spring Festival" directory. In this embodiment, U2 belongs to both the Spring Festival and Mid-autumn Festival directories.

Referring to Fig. 4a and Fig. 4b, Fig. 4a shows a schematic diagram of a user-defined data structure applying Embodiment 2 of the present invention, wherein, the box represents Folder, and the circle represents data Item; the state represented by the solid line is Existing, and the state represented by the dotted line The status is Updata. FIG. 4b is a schematic diagram of data storage of a client applying Embodiment 2 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The status of the data in each list is reflected in Figure 4b.

When a user asks to sync the "bless" directory, the client generates the following sync commands sequentially:

First, after the client determines that the synchronization data is a directory item according to the command received from the user to synchronize the bless directory, it determines the status of the bless from the Folder Table to be U, and then constructs a replacement (Replace) synchronization command, and, in The Meta field in the constructed command indicates that the data type determined according to the Folder Table is the directory item Folder, the LUID field indicates the number 1006 of the data to be synchronized, the Data field indicates that the specific data is bless, and the SourceParent field indicates that its parent directory is the root directory .

Afterwards, the client determines the status of the data item in the bless directory. Since the data item corresponding to 1006 in the Index Table is 2001, and its status is U, it constructs the Replace synchronization command and determines the corresponding data item of 2001 from the Data Item Table. After the specific data content is U1, the Meta field in the constructed Replace synchronization command indicates that the data type is Item, the LUID field indicates that the number of the data to be synchronized is 2001, the Data field indicates that the specific data is U1, and the SourceParent field indicates Its parent directory is 1006.

After that, when the client determines that there is no updated data item in the bless directory, it will index the status of the subdirectories under the bless directory. The specific method is the same as the method for determining the bless directory. In this example, the status of the subdirectories under the bless directory has not changed. , do not process.

Afterwards, when the client determines that there is no updated subdirectory under the bless directory, it determines the status of the data items under the subdirectory Spring Festival. The specific method is the same as the method for determining U1. That is, the final result is to construct the Replace synchronization command, and after determining from the Data Item Table that the specific data content corresponding to 2002 is U2, the Meta field in the constructed Replace synchronization command indicates that the data type is the data item Item, and the LUID field The number indicating the data to be synchronized is 2002, the Data field indicates the specific data is U2, and the SourceParent field indicates its parent directory is 1007.

By analogy, until the Replace synchronization command is issued for all the updated data, the recursive synchronization is realized in this way. Of course, if only a certain directory item is synchronized, and the data items under this directory item are no longer synchronized, the non-recursive synchronization is actually realized. In addition, it is also possible to only synchronize a certain directory item and the data items under the directory item without synchronizing the subdirectory items under the directory item.

Afterwards, all the constructed Replace synchronization commands are sent to the server, and the specific sending method is the same as that of sending the ADD synchronization command, which will not be repeated here.

The following describes the process of executing the synchronization operation after the server receives the above-mentioned Replace command. The table involved in this process is similar to the table shown in Figure 4b, so it is not shown in the figure.

When the server receives the synchronization command to update the bless directory item, it determines the type of the data to be synchronized as a directory item through the Meta field in the received synchronization command, and determines the serial number of the data to be synchronized on the client side as 1006 according to the LUID field. The Data field determines its name as bless, and its parent directory is determined as the root directory according to the SourceParent field. Afterwards, the local serial number of the updated data to be synchronized in the server is obtained from the set correspondence list between the serial number in the SyncML client and the serial number in the server; for example, 100006. Then, update the corresponding entry in the locally set directory table, that is, update the attribute information of bless in the corresponding relationship entry of 100006, bless, the root directory, and the current state of the bless data.

When the server side receives the synchronization command to update the U1 data item, it determines the type of the data to be synchronized as a data item through the Meta field in the received synchronization command, and determines the serial number of the data to be synchronized on the client side as 2001 according to the LUID field. The data field determines its specific data content as U1, and its parent directory is determined as 1006 according to the SourceParent field. After that, obtain the local number of the updated data to be synchronized on the server from the corresponding list of the number in the SyncML client and the number in the server that has been set, such as 200001, and update the data to be synchronized in the locally set data entry table The entry corresponding to the local serial number of the data is to update the U1 information in the entry corresponding to 200001 and U1.

The method for updating U2 at the server side is the same as the method for updating U1, and will not be repeated here.

One point needs to be explained here. In this example, U2 belongs to both the Spring Festival directory and the Mid-autumn Festival directory. However, when updating U2, you only need to send the Replace command once, and the server only needs to update U2 once to make the two directories Both U2's are updated. This is because only one piece of data is actually saved on the server side, and the affiliation of the data is reflected through the Index Table. It can be seen that the use of the method of the present invention can minimize the existence of redundant data, thereby saving limited resources to the greatest extent.

Embodiment 3: The user moves the data item "M1" under the "music" directory to the "favoriate" directory; moves the entire "mp3" directory to the "favorite".

Referring to Fig. 5a and Fig. 5b, Fig. 5a shows a schematic diagram of a user-defined data structure applying Embodiment 3 of the present invention, wherein, a square box represents a Folder, and a circle represents a data Item; the state represented by a solid line is Existing, and a double-dotted line represents The status is Move. FIG. 5b is a schematic diagram of data storage of a client applying Embodiment 3 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The status of data in each list is reflected in Figure 5b.

When the user requests to synchronize the root directory, the client generates the following synchronization commands in sequence:

First, the client indexes the status of all subdirectories under the root directory according to the command received from the user to synchronize the root directory. In this example, the status of all subdirectories under the root directory has not changed, so no deal with. Then, the client checks whether the status of the data items in the root directory changes. In this example, the status of the data items in the root directory does not change, so no processing is performed.

After that, the client sequentially indexes whether the status of the subdirectories in each subdirectory changes. In this example, the client determines that the status of the "mp3" subdirectory under the music directory is M. After that, the client constructs a Move (Move) synchronization command, and , the Meta field in the constructed command indicates that the data type determined according to the FolderTable is the directory item Folder, the LUID field indicates the number 1006 of the data to be synchronized, and the SourceParent field indicates that the parent directory to which it belongs after the move is 1004.

Afterwards, the client determines the status of the data item in the music directory. Since the data item corresponding to 1006 in the Index Table is 2001, and its status is M, a Move synchronization command is constructed, and the Meta in the constructed command The field indicates that the data type is Item, the LUID field indicates the number 2001 of the data to be synchronized, and the SourceParent field indicates that the parent directory to which it belongs after moving is 1004.

By analogy, there is no other data that has been moved in this case, so it will not be processed.

Afterwards, all the constructed MOVE synchronization commands are sent to the server, and the specific sending method is the same as that of sending the ADD synchronization command, which will not be repeated here.

The following describes the process of performing a synchronization operation after the server receives the above-mentioned Move command. The table involved in this process is similar to the table shown in Fig. 5b, so it is not shown in the figure.

When the server receives the synchronization command to move the mp3 directory item, the Meta field in the received synchronization command determines that the type of the data to be synchronized is a directory item, the LUID field determines that the number of the data to be synchronized on the client is 1006, and the SourceParent field After confirming that the parent directory to which it belongs after the move is 1004, obtain the local number of the data to be moved on the server from the corresponding list of the number in the SyncML client and the number in the server that has been set, such as 100006, which has been set locally In the Folder Table, change the parent directory of the entry corresponding to the local number of the data to be synchronized to the parent directory in the received synchronization command, that is, change the parent directory corresponding to 100006 in the table from 1005 to 1004.

When the server receives the synchronization command to move the M1 data item, the Meta field in the received synchronization command determines the type of the data to be synchronized as Item, the LUID field determines that the number of the data to be synchronized on the client is 2001, and the SourceParent field determines After its parent directory after the move is 1004, obtain the local serial number of the updated data to be synchronized in the local server, such as 200001, which has been set locally. In the Index Table, change the parent directory of the entry corresponding to the local number of the data to be synchronized to the parent directory in the received synchronization command, that is, change the parent directory corresponding to 200001 in the table from 1005 to 1004.

It can be seen that when the method of the present invention is used to perform the synchronization operation of movement, only the corresponding relationship in the corresponding data table needs to be modified, and the actual data does not need to be moved, thereby saving limited resources to the greatest extent.

Another point needs to be explained: when moving a directory and its subdirectories and data items, such as when moving an mp3 directory item, you only need to send a MOVE command for the mp3 directory item, instead of targeting the subdirectories under the mp3 directory. Directories and data items send the MOVE command, because the parent directory to which the subdirectories and data items belong to has not changed.

Embodiment 4: The user deletes the "D1" data item under the "bless" directory, chooses to permanently delete the data "U2" under the "SpringFestival" directory, and selects non-permanent deletion for "D3". In this example, it is only a description of the deleted data item.

Referring to Figure 6a and Figure 6b, Figure 6a shows a schematic diagram of a user-defined data structure applying Embodiment 4 of the present invention, wherein, the box represents Folder, and the circle represents data Item; the state represented by the solid line is Existing, and the state represented by the dotted line Status is Delete. FIG. 6b is a schematic diagram of data storage of a client applying Embodiment 4 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The status of the data in each list is reflected in Figure 6b.

When a user asks to sync the "bless" directory, the client generates the following sync commands sequentially:

The client determines the status of the data item in the bless directory. Since the status of the data item in the Index Table is 2001, it is permanently deleted P-D. Therefore, the delete synchronization command is constructed. The Meta field in the constructed Delete synchronization command indicates that the data type is In the data item Item, the LUID field indicates that the serial number of the data to be synchronized is 2001, and the command also needs to include an identifier indicating permanent deletion.

Afterwards, when the client determines that there is no deleted data item in the bless directory, it will index the status of the subdirectories under the bless directory. In this example, the status of the subdirectories under the bless directory has not changed and will not be processed.

After the client confirms that there are no deleted subdirectories under the bless directory, it then determines the status of the data items under the subdirectory SpringFestival. The specific method is the same as the method for determining D1. That is, the final result is to construct two Delete synchronization commands. The Meta field in one of the Delete synchronization commands indicates that the data type is the data item Item, and the LUID field indicates that the number of the data to be synchronized is 2002, and the command also needs to include the specified Identifier for permanent deletion. The Meta field in another Delete synchronization command indicates that the data type is a data item, the LUID field indicates that the serial number of the data to be synchronized is 2003, and the command also needs to include an identifier indicating non-permanent deletion.

The constructed Delete command does not need to include the data to be deleted, but only needs to indicate the type, number, and whether to delete permanently or non-permanently. The above is an implementation of the Delete command, that is, the command contains three types of information: type, number, and whether it is permanently deleted or not permanently deleted; of course, there are other implementations, for example, the Delete is divided into two commands , a P-Delete command for permanent deletion, and an NP-Delete command for non-permanent deletion. In this way, each type of deletion command only needs to include the type and number of the data to be deleted.

Afterwards, all the constructed synchronization commands for instructing deletion are sent to the server.

The following describes the process of performing a synchronization operation after the server receives the above-mentioned Delete command.

When the server side receives the synchronization command to delete the D1 data item, it determines the type of the data to be synchronized as the data item Item through the Meta field in the received synchronization command, and determines the serial number of the data to be synchronized on the client side as 2001 according to the LUID field. And confirm that this deletion is a permanent deletion, after that, obtain the local number of the data to be deleted in the server local number, such as 200001, in the local data entry Table and data entry-directory correspondence table, respectively delete the entry corresponding to the local number of the data to be synchronized, that is, delete the entire entry with the number 200001. At the same time, delete the D1 data in the local database.

When the server side receives the synchronization command to delete the data item of D2, it deletes the entire entry in the corresponding data table. The method of deleting D2 is the same as the method of deleting D1, and will not be repeated here.

When the server side receives the synchronization command to delete the D3 data item, the Meta field in the received synchronization command determines that the type of the data to be synchronized is the data item Item, and the serial number of the data to be synchronized on the client side is determined to be 2003 according to the LUID field. And confirm that this deletion is non-permanent deletion, after that, obtain the local number of the data to be deleted in the server local number in the corresponding list of the number in the SyncML client and the number in the server that has been set, such as 200003, only in the local Delete the entry corresponding to the local number of the data to be synchronized in the data entry-directory correspondence table, that is, delete the entire entry numbered 200003 in the table. D3 data is not deleted in the local database.

It can be seen that when the method of the present invention is used to perform the synchronization operation of deletion, only the identifier needs to be transferred between the client and the server, and no specific data content needs to be transmitted, which saves limited resources to the greatest extent.

Embodiment 5: The user deletes the entire "bless" directory. This is equivalent to deleting all subdirectories under it and all data items under it at the same time. In this example, D1 and D2 exist only in the bless directory, and D3 exists in the bless and joke directories, and this example is only a description of deleting directory items.

Referring to Fig. 7a and Fig. 7b, Fig. 7a shows a schematic diagram of a user-defined data structure applying Embodiment 5 of the present invention, wherein, a square box represents a Folder, and a circle represents a data Item; the state represented by a solid line is Existing, and the state represented by a dotted line Status is Delete. Fig. 7b is a schematic diagram of data storage of a client applying Embodiment 5 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The status of the data in each list is reflected in Figure 7b.

When the user requests to synchronize the root directory, the client generates the following synchronization commands in sequence:

First, the client indexes the status of all subdirectories under the root directory according to the command received from the user to synchronize the root directory. In this example, if the status of bless is determined to be D from the Folder Table, the client also It should further include: judging whether the data items in the directory to be deleted and the data items in the subdirectories of the directory only exist in the directory to be deleted, if so, constructing a delete command, and the delete command contains instructions to permanently information to be deleted; otherwise, construct a delete command for each data item and directory item, and only the data item or directory item corresponding to the directory to be deleted contains information indicating permanent deletion, not only The delete command corresponding to the data item or directory item existing in the directory to be deleted includes information indicating non-permanent deletion. That is to say, if a data item or directory item still exists in other directories (the other directories here do not include the bless subdirectory), the delete command corresponding to such data will include non-permanent deletion information, if not For such data, the corresponding deletion command includes permanent deletion information. Afterwards, all the constructed delete synchronization commands are sent to the server. Here, constructing a delete command for each data item and directory item is actually a recursive synchronization.

The following describes the process of performing a synchronization operation after the server receives the above-mentioned Delete command.

If the server receives a delete command for a data item, the processing method is the same as that described in Embodiment 4 and will not be repeated here.

If the server receives a delete command for a directory item, it will obtain the local number of the data to be deleted in the server's local number from the set correspondence list between the number in the SyncML client and the number in the server, regardless of whether it is permanently deleted Whether it is a non-permanent deletion or not, the entry corresponding to the local number of the data to be synchronized is deleted in the locally set directory table.

There is one more thing to explain about the directory deletion operation: as the request initiator, when deleting a certain directory item, such as deleting a bless directory item, it can only construct a delete command for this directory item, while the other commands it executes Operations, such as "judging whether the data items in the directory to be deleted and the data items in the subdirectories of the directory only exist in the directory to be deleted", etc., are all performed by the server, which can simplify the operation of the client. Of course, the reverse also applies.

In practical applications, Embodiments 4 and 5 are usually combined and used simultaneously.

In addition, for the deletion operation, after the synchronization operation is completed on the server side, the client terminal will also delete the entries in its own corresponding data table.

Embodiment 6: The user copies the data item "M1" under the "music" directory to the "favoriate" directory; copies the "mp3" directory to the "favorite" directory.

Referring to Figure 8a and Figure 8b, Figure 8a shows a schematic diagram of a user-defined data structure applying Embodiment 6 of the present invention, wherein, a box represents a Folder, and a circle represents a data Item; the state represented by a solid line is Existing, and the thick solid line represents The status is Copy. FIG. 8b is a schematic diagram of data storage of a client applying Embodiment 6 of the present invention. The data item table Data Item Table, the directory table Folder Table and the "data item-directory" corresponding relationship index table Index Table are saved on the client side. The states of the added data in each list are correspondingly reflected in Fig. 3b.

When the user requests to synchronize the root directory, the operations of the client and the server are basically the same as those in Embodiment 1. The difference is that, in Embodiment 1, the client sends an ADD command for each data item and directory entry, but in this example, if the client sends a Copy command to a directory entry, it is not necessary to The subdirectory items and data items under the directory item will issue commands again, thereby further reducing the transmission of data volume and saving network resources. However, the processing procedure at the server side in this example is the same as that in Embodiment 1, and it also processes each directory item and data item one by one.

Furthermore, when performing Copy synchronization, the user can decide according to needs whether to instruct to copy a copy of the actual data, and if so, the operation of realizing data synchronization at the end of the synchronization operation further includes: copying a copy of data in the local database , and add corresponding entries in the locally set data directory table.

If there is a conflict between the modification operations of the client and the server, such as adding, updating or deleting some entries in the moved directory, the existing conflict mechanism is extended to ensure that the data on the client and server are fully synchronized. The specific implementation is: to extend the existing arbitration results based on client-side (Client-Win) and server-side (Server-Win), and add a combination of server-side and client-side (Win-Win ), through a win-win approach to ensure that the data on the client and server are completely consistent.

For example, if the user moves directory A on the client to make it a subdirectory of directory B, and the server adds an entry to directory A, at this time, directory A will be moved on the server to become a subdirectory of directory B , and also add an entry in the A directory on the client side, so as to ensure that the data on the client side and the server side are completely consistent.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of the present invention. within the scope of protection.

Claims (19)

1, a kind ofly realizes it is characterized in that the method for data sync that when the termination in SyncML client or the server end was received synchronization request from the user, the client and server end consulted to treat catalogue under the synchrodata at the SyncML layer; This method may further comprise the steps:

Treat the type of synchrodata in the request synch command that a end in a, SyncML client or the server end is at first determined to receive, if directory entry, execution in step b then is if data items, then execution in step c;

B, from the catalogue listing that has been provided with, obtain the current state that this treats synchrodata, if being designated as, current state do not change, then do not process, if current state is designated as variation, then make up corresponding with it data sync order, this data sync order is sent to the other end in client or the server end according to this variable condition;

C, from the data clauses and subclauses-catalogue mapping table that has been provided with, obtain the variable condition that this treats synchrodata, and make up corresponding with it data sync order according to this variable condition, this data sync order is sent to the other end in client or the server end;

At least comprise the data type for the treatment of synchrodata and treat the synchrodata numbering in the described constructed order;

After the other end in SyncML client or the server receives synch command from the opposite end, carry out following steps:

Action type is determined in the data sync order that d, basis receive, and changes the content of corresponding form, realizes data sync.

2, method according to claim 1 is characterized in that, described initiation synchronization request be client, described execution simultaneous operation be server end;

The described variable condition that this treats synchrodata is newly-increased N, and described is to increase the ADD synch command with the corresponding data sync order of this variable condition; The synchrodata numbering treated in described this order is the numberings of these data in client, and further comprises in this order: concrete synchrodata and the affiliated parent directory of this data treated;

Described server end determines that action type is increase; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

According to the data sync order that receives, preserve the synchrodata for the treatment of that receives at local data base, for this treats the local numbering of synchrodata distribution server, this synchrodata of preservation is at the numbering of client and this synchrodata corresponding relation in the numbering of server end in the numbering in the SyncML client that has been provided with and the tabulation of the corresponding relation of the numbering in the server; And, according to the data type for the treatment of synchrodata in the synch command, determine the type of this synchrodata, if data type is a directory entry, then in the catalogue listing that this locality has been provided with, increase respective entries, if data type is a data items, then increase respective entries in the data table of articles that has been provided with in this locality and the data clauses and subclauses-catalogue corresponding relation concordance list.

3, method according to claim 1 is characterized in that, described initiation synchronization request be server end, described execution simultaneous operation be client;

The described variable condition that this treats synchrodata is newly-increased N, and described is to increase the ADD synch command with the corresponding data sync order of this variable condition; The synchrodata numbering treated in described this order is the numberings of these data at server end, and further comprises in this order: concrete synchrodata and the affiliated parent directory of this data treated;

Described client determines that action type is increase; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

According to the data sync order that receives, preserve the synchrodata for the treatment of that receives at local data base, treat synchrodata for this and distribute the client terminal local numbering, and, according to the data type for the treatment of synchrodata in the synch command, determine the type of this synchrodata, if data type is a directory entry, then in the catalogue listing that this locality has been provided with, increase respective entries, if data type is a data items, then increase respective entries in the data table of articles that has been provided with in this locality and the data clauses and subclauses-catalogue corresponding relation concordance list; Afterwards, return the numbering in this data client and the corresponding relation of the numbering in the server to server end, the corresponding relation that receives is kept in numbering in the local SyncML client that has been provided with tabulates with the corresponding relation of the numbering in the server by server end.

4, according to claim 2 or 3 described methods, it is characterized in that, after step b is finished, further comprise: e judges under this directory entry that increases newly whether the data items that increases newly is arranged, if have, repeated execution of steps c then, up to all data items all synchronously till, execution in step f afterwards; If no, direct execution in step f then;

F, judge whether the subdirectory item that increases newly is arranged under this directory entry that increases newly, if having, repeated execution of steps b then, up to all directory entries all synchronously till, execution in step e if do not have, then finishes afterwards.

5, according to claim 2 or 3 described methods, it is characterized in that, after step b is finished, further comprise: e judges under this directory entry that increases newly whether the data items that increases newly is arranged, if have, repeated execution of steps c then, up to all data items all synchronously till.

6, method according to claim 1 is characterized in that,

The described variable condition that this treats synchrodata is for upgrading U, and described and the corresponding data sync order of this variable condition be for replacing the Replace synch command, and further comprises in this order: concrete synchrodata and the affiliated parent directory of these data treated;

The described other end determines that action type is renewal; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

According to the data sync order that receives, determine the type of this synchrodata, if data type is a directory entry, then in the catalogue listing that this locality has been provided with, upgrade and treat that synchrodata is in the pairing clauses and subclauses of the numbering of this locality, if data type is a data items, then in the data table of articles that this locality has been provided with, upgrades and treat that synchrodata is in the pairing clauses and subclauses of the numbering of this locality.

7, method according to claim 6, it is characterized in that, after step b is finished, further comprise: g judges under this directory entry that has upgraded whether the data updated project is arranged, if have, repeated execution of steps c then, up to all data items all synchronously till, execution in step h afterwards; If no, direct execution in step h then;

H, judge the subdirectory item that whether has renewal under this directory entry that has upgraded, if having, repeated execution of steps b then, up to all directory entries all synchronously till, execution in step g if do not have, then finishes afterwards.

8, method according to claim 6 is characterized in that, after step b is finished, further comprise: g judges under this directory entry that has upgraded whether the data updated project is arranged, if have, repeated execution of steps c then, up to all data items all synchronously till.

9, method according to claim 1 is characterized in that,

Described this treats that the variable condition of synchrodata is mobile M, and the described and corresponding data sync order of this variable condition is mobile Move synch command; And further comprise in this order: parent directory under these data after changing;

The described other end determines that action type is mobile; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

According to the data sync order that receives, determine the type of this synchrodata, if data type is a directory entry, then in the catalogue listing that this locality has been provided with, this is treated that synchrodata parent directory under the pairing clauses and subclauses of the numbering of this locality changes to the parent directory in the synch command that receives, if data type is a data items, will treat in data clauses and subclauses-catalogue mapping table that this locality has been provided with that then synchrodata parent directory under the pairing clauses and subclauses of the numbering of this locality changes to the parent directory in the synch command that receives.

10, method according to claim 1 is characterized in that, the described current state of step b is designated as deletion D, and described is to delete the Delete synch command with the corresponding data sync order of this variable condition; One end of then described initiation synchronization request further comprises: judge whether data items under the subdirectory of this data items under waiting to deltree and this catalogue exists only in this and wait to deltree down, if, then make up a delete command, and comprise the information of indicating permanent delet in this delete command; Otherwise, make up a delete command respectively at each data items and directory entry, and existing only in this data items under waiting to deltree or the pairing delete command of directory entry and comprise the information of indicating permanent delet, is not to exist only in this data items under waiting to deltree or the pairing delete command of directory entry to comprise the information of indicating impermanent deletion;

The described other end determines that action type is deletion; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

Determine the deletion type according to the data sync order that receives, and the data type for the treatment of synchrodata, if data type is a directory entry, no matter be that the deletion type is permanent delet or impermanent deletion then, all deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality in the catalogue listing that this locality has been provided with; If data type is a data items, and the deletion type is a permanent delet, then in local data base, delete these data, and in data table of articles and data clauses and subclauses-catalogue mapping table that this locality has been provided with, deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality respectively; If data type is a data items, and the deletion type be impermanent deletion, then in the data clauses and subclauses-catalogue mapping table of this locality the deletion treat that synchrodata is in the pairing clauses and subclauses of the numbering of this locality.

11, method according to claim 1 is characterized in that, the described current state of step b is designated as deletion D, and described is to delete the Delete synch command with the corresponding data sync order of this variable condition;

The described other end determines that action type is deletion; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

Determine the deletion type according to the data sync order that receives, and the data type for the treatment of synchrodata, if data type is a directory entry, judge again then whether the subdirectory of this data items under waiting to deltree and this catalogue and the data items under the subdirectory exist only in this and wait to deltree down, if, then determine this wait to deltree and this catalogue under data items, be permanent delet with the data items under subdirectory and the subdirectory, otherwise, determining to wait to deltree and to exist only in this data items or directory entry under waiting to deltree at this is permanent delet, at being not that to exist only in this data items or directory entry under waiting to deltree be impermanent deletion;

If deletion is directory entry, no matter be that the deletion type is permanent delet or impermanent deletion then, all deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality in the catalogue listing that this locality has been provided with; If deletion is data items, and the deletion type is a permanent delet, then in local data base, delete these data, and in data table of articles and data clauses and subclauses-catalogue mapping table that this locality has been provided with, deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality respectively; If data type is a data items, and the deletion type be impermanent deletion, then in the data clauses and subclauses-catalogue mapping table of this locality the deletion treat that synchrodata is in the pairing clauses and subclauses of the numbering of this locality.

12, method according to claim 1 is characterized in that, the described variable condition of step c is deletion D, and described is to delete the Delete synch command with the corresponding data sync order of this variable condition; One end of then described initiation synchronization request further comprises: judge receive from whether indicating this data items of permanent delet in user's the delete command, if, the sign that further comprises permanent delet in the then described delete command, otherwise, judge that this treats whether the deleted data project is positioned under a plurality of catalogues, if in described delete command, further comprise the sign of impermanent deletion, otherwise further comprise the sign of permanent delet in the described delete command;

The described other end determines that action type is deletion; The content of the corresponding form of described change, realize that the process of data sync may further comprise the steps:

After being data items according to the data sync order specified data type that receives, determine the deletion type again, if the deletion type is a permanent delet, then in local data base, delete these data, and in data table of articles and data clauses and subclauses-catalogue mapping table that this locality has been provided with, deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality respectively; If the deletion type is impermanent deletion, then deletion treats that synchrodata is in the pairing clauses and subclauses of the numbering of this locality in the data clauses and subclauses-catalogue mapping table of this locality.

13, according to claim 10,11 or 12 described methods, it is characterized in that, after the deletion simultaneous operation that is finished as the client of carrying out simultaneous operation or the server other end, further comprise: an end of initiating synchronization request is deleted the corresponding data project in the corresponding data table that this locality has been provided with.

14, according to claim 6,9,10,11 or 12 described methods, it is characterized in that,

If described initiation synchronization request is client, what carry out simultaneous operation be server end, treats that it is the numberings of these data in client that synchrodata is numbered in the then described synch command; After described server end receives the data sync order, the specified data type takes a step forward and comprises: that obtains this renewal in the tabulation of the numbering in the SyncML client that has been provided with and the corresponding relation of the numbering in the server treats the numbering of synchrodata in server this locality, continues to carry out subsequent operation afterwards again.

If described initiation synchronization request is server end, what carry out simultaneous operation be client, and the synchrodata numbering for the treatment of in the then described synch command is the corresponding relation of numbering in the client that has been provided with according to self of server end and the numbering in the server these data of obtaining numbering in client of tabulating.

15, method according to claim 1, it is characterized in that, in the described catalogue listing that in SyncML client and server, is provided with respectively, comprise the parent directory under directory entry numbering, directory name, this catalogue key name and the corresponding relation of this directory entry state at least;

In the described data clauses and subclauses-catalogue corresponding relation concordance list that in SyncML client and server, is provided with respectively, comprise the corresponding relation of data items numbering, parent directory and data items state at least.

16, according to claim 2,3 arbitrary described methods, it is characterized in that, comprise at least in the described data table of articles that in SyncML client and server, is provided with respectively: the corresponding relation of data items numbering and concrete data content;

Described in the SyncML client that server end has been provided with numbering and the tabulation of the corresponding relation of the numbering in the server in comprise at least: the numbering of data in client and the corresponding relation of the numbering in the server.

17, method according to claim 1, it is characterized in that, the initial phase that operates in of catalogue under the synchrodata is treated in described negotiation, and may further comprise the steps: the form to URI is made predefine, and the implication by URI in the target database element indicates treats synchronous directory.

18, method according to claim 1 is characterized in that, the initial phase that operates in of catalogue under the synchrodata is treated in described negotiation, may further comprise the steps: indicate by filtercondition in the filtercondition element and treat synchronous directory.

19, method according to claim 1 is characterized in that, this method further comprises: set up the arbitration result that merges processing (Win-Win) with server end and client;

When the retouching operation of server end and client clashed, client was carried out simultaneous operation according to the modification of server end, and server end is carried out simultaneous operation according to the modification of client;

That described modification comprises is newly-increased, upgrade, move, deletion, copy operation.

Images