System and method for collaborative editing of electronic objects

Abstract

A computer-implemented method for editing an electronic object is described herein. The method includes maintaining a local version of the electronic object and a local buffer that includes one or more local deltas. A plurality of server deltas are received from a server system, each server delta relating to a remote edit made to the electronic object. The plurality of server deltas are composed to generate a single composed server delta, which is transformed against the one or more local deltas to generate a transformed server delta. The local version of the electronic document is then edited by applying the transformed server delta to the local version of the electronic document.

Description

Technical Field

[0001] This disclosure relates to systems and methods for collaborative editing of electronic objects. Background of the Invention

[0003] Real-time collaborative editing platforms allow multiple users to work on the same electronic object simultaneously from different computing systems. For example, Google Docs allows multiple users (through their different user systems) to view and edit document-type objects at the same time.

[0004] Some real-time collaborative editing platforms are supported by Operation Transformation (OT) synchronization protocols, which are generally used to transform different edits made to objects by different users in order to maintain object consistency.

[0005] The processing involved in performing operational transformations can be important, especially when the number of concurrent users on the object and / or the number of edits performed by these users is large.

[0006] References to background information in this specification are not intended to imply that such information is prior art or common knowledge to those skilled in the art. Summary of the Invention

[0007] This document describes a computer-implemented method for editing an electronic object, which is edited in real time by multiple client applications. The method is executed by a first client application and includes: maintaining a local version of the electronic object; maintaining a local buffer, the local buffer including one or more local increments, each local increment describing one or more edits made by a user of the first client application to the local version of the electronic document; receiving multiple server increments from a server system, each server increment relating to a remote edit made to the electronic object; composing the multiple server increments to generate a single composed server increment; transforming the single composed server increment against the one or more local increments in the local buffer to generate a transformed server increment; and editing the local version of the electronic document by applying the transformed server increment to the local version of the electronic document. Attached Figure Description

[0008] In the attached diagram:

[0009] Figure 1 An example network environment that allows for real-time collaborative editing is shown.

[0010] Figure 2 This is a block diagram of a computer processing system that can be configured to perform the various features of this disclosure.

[0011] Figure 3 This is a sample message transmission diagram.

[0012] Figure 4 This is a sample message transmission diagram.

[0013] Figure 5 The operation of the client synchronization module is described.

[0014] Figure 6 An example state-space diagram is provided.

[0015] Figure 7 This is an example state-space diagram.

[0016] Figure 8 The operation of the server synchronization module is described.

[0017] Figure 9 An example state-space diagram is provided.

[0018] Figure 10 An example state-space diagram is provided.

[0019] Figure 11 This is an example state-space diagram.

[0020] Figure 12 This is an example state-space diagram.

[0021] While the claimed invention may be modified and alternatively implemented in various ways, specific embodiments are shown by way of example in the accompanying drawings and described in detail. However, it should be understood that the drawings and detailed description are not intended to limit the invention to the specific forms disclosed. Their purpose is to cover all modifications, equivalents, and alternatives that fall within the scope of the invention as defined by the appended claims. Detailed Implementation

[0022] The following description sets forth numerous specific details to provide a comprehensive understanding of the claimed invention. However, it will be apparent that the claimed invention can be practiced without these specific details. In some cases, to avoid unnecessary ambiguity, well-known structures and devices are shown in block diagram form.

[0023] Overview

[0024] In general, this disclosure provides techniques that allow multiple users (people or programs) to view and edit electronic objects simultaneously (or substantially simultaneously).

[0025] The described technology can be applied to various types of electronic objects, such as documents, presentations, web pages, images, designs, and other types of objects.

[0026] The system and processing described herein provide a managed dialog model for collaborative editing of objects. In such a model, a server (e.g., server application 110 described below) maintains a canonical copy of an object that can be collaboratively edited via a client application (e.g., client application 120).

[0027] To edit (or simply view) a given object, a user establishes a connection with the server via their client application and requests access to the specific object. Once the connection is established, the user can view the object on their client device (via their client application) and perform local edits in a lock-free, non-blocking manner. These edits are then synchronized with the server, which broadcasts the edits from each client back to all other connected clients.

[0028] Based on the edits submitted by the client, the server generates a linear history of operations on the managed objects. This history is understood by all parties as the "source of truth" of the specification.

[0029] In addition, each client maintains its history of edits performed. This disclosure describes synchronization performed at each end of the client-server connection to resolve the client's local edit history against a server-specific history containing edits from all other clients.

[0030] Various collaborative editing platforms exist. One such platform is Google Wave. However, the technology described in this article differs from platforms such as Google Wave in many ways.

[0031] For example, the protocol described in this article allows clients to send multiple commits at once, instead of being forced to send one commit at a time. This results in a smoother collaboration experience.

[0032] As another example, the client (and server) can arbitrarily buffer / arrange messages in transit and compress them into a single message before transformation, thus achieving synchronization more efficiently than existing technologies.

[0033] As a further example, the protocol described herein supports an architecture with proxies or intermediaries, allowing multiple clients to be multiplexed through a single proxy machine.

[0034] Other differences and advantages will become apparent from the published content.

[0035] Network environment

[0036] Figure 100 depicts an example of a network environment 100 capable of performing the various operations and techniques described herein.

[0037] Environment 100 includes a collaborative server system 102 (hereinafter referred to as server system 102), which communicates with a collaborative client system 104 via one or more communication networks 106.

[0038] Collaboration server system 102 hosts collaboration server application 110 (referred to as server application or SA110). SA110 is executed by server system 102 to configure it to provide server-side functionality to one or more corresponding client applications (e.g., client applications 120A and 120B described below). SA110 includes one or more applications, libraries, APIs, or other software elements that implement the features and functions described herein. For example, if CA120 is a web browser, SA110 will be a web server such as Apache, IIS, nginx, GWS, or an alternative web server. If CA120 is a dedicated collaboration platform application, SA110 will be an application server specifically configured to interact with CA120.

[0039] Server system 102 can host network servers and application servers (or multiple network / application servers, if needed).

[0040] In this example, SA 110 includes (or is accessible to) a synchronization module 112 (referred to as server SM 112). As described below, server SM 112 operates to synchronize edits received at SA 110 from various client applications 120 and maintains the specification history of all objects used by SA 110 for editing.

[0041] In the example shown, server SM 112 is shown as part of SA 110. This could be because these modules are native to SA 110 or installed as an extension / plugin / add-on to SA 110. In an alternative embodiment, server SM 112 may be a standalone program running on server system 102 (or on the same computer processing system running SA 110, or on a different computer processing system) and communicating with SA 110.

[0042] Server system 102 also includes server data storage 114 for storing data relevant to its operation. Server data storage 114 can be any system or combination of systems suitable for storing and accessing data. For example, server data storage 114 can be a database accessed by a suitable database front end.

[0043] Each collaboration client system 104 hosts a collaboration client application 120 (referred to as CA 120), which, when executed by the collaboration client system 104, is configured to provide client functionality and interact with the server system 102 (or, more specifically, the SA 110 running on it).

[0044] CA 120 can be a general-purpose web browser application (such as Chrome, Safari, Internet Explorer, Opera, or an alternative web browser application) that accesses SA 110 via an appropriate Uniform Object Locator (URL) and communicates with SA 110 via general-purpose World Wide Web protocols (e.g., http, https, ftp). Alternatively, CA 120 can be a dedicated collaborative application programmed to communicate with SA 110 using defined application programming interface (API) calls.

[0045] In this example, CA 120 includes EM 122 (hereinafter referred to as EM 122) and client synchronization module 124 (hereinafter referred to as client SM 124). Generally, EM 122 provides users of client system 104 with an editing interface that can be used to make changes to objects (e.g., through normal editing operations). EM 122 also prompts the display of changes made to objects based on messages received from SA 110 (i.e., edits made to objects at other CA 120s). Client SM 124 operates to synchronize the edits made by users of client system 104 and received at SA 110.

[0046] EM 122 and client SM 124 are described as part of CA 120. EM 122 and client SM 124 may be native to CA 120 or installed as an extension / plugin / add-on to CA 120. In an alternative embodiment, EM 122 and / or client SM 124 may be standalone programs running on client system 104 and communicating with CA 120.

[0047] A given collaborative client system 104 may have more than one CA 120, such as a general web browser application and a dedicated programming client application.

[0048] The collaborative client system 104 also includes a client data storage 126 for storing data related to its operation. Typically, the client data storage 126 will be the local storage of the client system 104 (e.g., volatile memory 208 and / or non-transitory memory 210 as described below); however, the client system's data storage can be, for example, a remote data storage accessible via network 106.

[0049] The collaborative server system 102 and the collaborative client system 104 transmit data to each other directly or indirectly through one or more communication networks 106. The communication network 106 may include a local area network (LAN), a public network, or a combination of networks.

[0050] Environment 100 is depicted as a single logical collaborative server 110. This could be a single collaborative server application running on a single computer processing system. Alternatively, server system 102 could be a clustered server architecture, wherein multiple server instances (or nodes) are provided on one or more computer processing systems to meet system requirements.

[0051] Environment 100 shows two client systems 104A and 104B; however, a typical environment 100 may include more client systems 104 that communicate with the collaborative server system 102.

[0052] The collaborative server system 102 can be any computer processing system configured (or configurable) by hardware and / or software to provide server-side functionality. Similarly, the client system 104 can be any computer processing system configured (or configurable) by hardware and / or software to provide client-side functionality. For example, suitable client and / or server systems may include server computer systems, desktop computers, laptop computers, netbook computers, tablet computing devices, mobile / smartphones, personal digital assistants, personal media players, set-top boxes, and game consoles.

[0053] The following text is for reference only. Figure 2 An example of a computer processing system is described.

[0054] Computer processing system

[0055] Various embodiments and features of this disclosure are implemented using one or more computer processing systems. For example, in Figure 1 In this system, each client system 104 is a computer processing system, and the server system 102 includes one or more computer processing systems.

[0056] Figure 2 A block diagram is provided of a computer processing system 200 that can be configured to implement the embodiments and / or features described herein. System 200 is a general-purpose computer processing system. It should be understood that... Figure 2Not all functional or physical components of the computer processing system are shown. For example, a power supply or power interface is not depicted; however, system 200 will carry a power supply or be configured to connect to a power supply (or both). It will also be understood that a particular type of computer processing system will determine appropriate hardware and architecture, and alternative computer processing systems suitable for implementing the features of this disclosure may have additional components, alternative components, or fewer components than those described.

[0057] The computer processing system 200 includes at least one processing unit 202. The processing unit 202 may be a single computer processing device (e.g., a central processing unit, graphics processing unit, or other computing device), or it may include multiple computer processing devices. In some cases, all processing will be performed by the processing unit 202; however, in other cases, processing may also be performed by a remote processing device that can be accessed and used by the system 200 (in a shared or dedicated manner).

[0058] Through communication bus 204, processing unit 202 communicates with one or more machine-readable storage (memory) devices that store instructions and / or data to control the operation of processing system 200. In this example, system 200 includes system memory 206 (e.g., BIOS), volatile memory 208 (e.g., random access memory such as one or more DRAM modules), and non-volatile memory 210 (e.g., one or more hard disks or solid-state drives).

[0059] System 200 also includes one or more interfaces, generally denoted by 212, through which system 200 engages with various devices and / or networks. Generally, other devices may be integrated with system 200 or may be separate. When a device is separate from system 200, the connection between the device and system 200 may be via wired or wireless hardware and communication protocols, and may be direct or indirect (e.g., networking).

[0060] Wired connections to other devices / networks can be made via any suitable standard or proprietary hardware and connectivity protocol. For example, system 200 can be configured to make wired connections to other devices / communication networks via one or more of the following: USB; FireWire; eSATA; Thunderbolt; Ethernet; OS / 2; Parallel; Serial; HDMI; DVI; VGA; SCSI; audio port. Other wired connections are also possible.

[0061] Similarly, wireless connectivity with other devices / networks can be established via any suitable standard or proprietary hardware and communication protocol. For example, system 200 can be configured to wirelessly connect with other devices / communication networks using one or more of the following: infrared; Bluetooth; WiFi; Near Field Communication (NFC); ​​Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Long Term Evolution (LTE), Wideband Code Division Multiple Access (W-CDMA), and Code Division Multiple Access (CDMA). Other wireless connections are also possible.

[0062] Generally, depending on the specific system, devices connected to system 200 (whether wired or wireless) include: one or more input devices to allow data to be input to / received by system 200 for processing by processing unit 202; and one or more output devices to allow data to be output by system 200. Example devices are described below; however, it should be understood that not all computer processing systems will include all of the mentioned devices, and additional and alternative devices to those mentioned may be used.

[0063] For example, system 200 may include or be connected to one or more input devices through which information / data is input to (and received by) system 200. Such input devices may include a keyboard, mouse, trackpad, microphone, accelerometer, proximity sensor, GPS device, etc. System 200 may also include or be connected to one or more output devices controlled by system 200 to output information. Such output devices may include devices such as CRT displays, LCD displays, LED displays, plasma displays, touchscreen displays, speakers, vibration modules, LEDs / other lights, etc. System 200 may also include or be connected to devices that can act as both input and output devices, such as storage devices (hard disk drives, solid-state drives, disk drives, compressed flash memory cards, SD cards, etc.) from which system 200 can read data and / or write data, and touchscreen displays that can display (output) data and receive touch signals (input).

[0064] System 200 can also be connected to one or more communication networks (e.g., the Internet, local area network, wide area network, personal hotspot, etc.) to transmit data to and receive data from networked devices, which themselves can be other computer processing systems.

[0065] System 200 may be any suitable computer processing system, such as, by way of non-limiting example, a server computer system, a desktop computer, a laptop computer, a netbook computer, a tablet computing device, a mobile / smartphone, a personal digital assistant, or an alternative computer processing system.

[0066] Typically, system 200 includes at least user input and output devices 214 and a communication interface 216 for communicating with a network such as network 106 of environment 100.

[0067] System 200 stores or accesses computer application programs (also known as software or programs), i.e., computer-readable instructions and data, which, when executed by processing unit 202, configure system 200 to receive, process, and output data. Instructions and data may be stored on a non-transitory machine-readable medium accessible to system 200. For example, instructions and data may be stored on non-transitory memory 210. Instructions and data may be transmitted to or received by system 200 via data signals in a transmission channel implemented by an interface (e.g., 212) via, for example, a wired or wireless network connection.

[0068] Applications accessible to System 200 typically include operating system applications, such as Microsoft... Apple OSX, Apple iOS, Android, Unix, or Linux.

[0069] System 200 also stores or accesses applications that, when executed by processing unit 202, configure system 200 to perform the various computer-implemented processing operations described herein.

[0070] For example, refer to the above Figure 1 In the network environment, each client system 104 includes a client application 120, which configures the client system 104 to perform the client system operations, and the server system 102 includes a server application 110, which configures the server system 102 to perform the server system operations.

[0071] In some cases, part or all of a given computer-implemented method will be executed by system 200 itself, while in other cases, the processing may be performed by other devices that communicate data with system 200.

[0072] Object version

[0073] In this disclosure, SA 110 and each CA 120 maintain a version identifier for a given object that is being (or has been) edited.

[0074] Client and server version identifiers (abbreviated as CV and SV, respectively) are independent; that is, a given client version identifier for a specific object is unrelated to another client version identifier or the server version identifier for that object. A given client version identifier allows that client to track the object's own, local state, and allows the server to track the state of the object for that specific client. The server version identifier is used to track the server version (canonical version) of the object.

[0075] The protocol described herein requires ordering a given set of version identifiers (i.e., version identifiers maintained by a specific CA 120 or version identifiers maintained by SA 110), but does not require any concept of "distance" between two version identifiers.

[0076] For example, one possible implementation of this type of version identifier is an ordinal number, such as a monotonically increasing sequence of integers, e.g., (0, 1, 2, ...). In some implementations, the client version identifier takes this form.

[0077] As another example, a timestamp can be used together with a sequence number (the sequence number used when two timestamps happen to be identical) as a version identifier, for example, (1585091071632-0, 1585091874453-0, 1585091874453-1, 1585091875337-0, ...). In some implementations, the SA 110 maintains server version identifiers in this form. Specifically, the SA 110 can be configured to use a data store such as Redis for the canonical history of objects. In this case, a Redis streaming data type can be used, which automatically assigns such version numbers when items are added to the stream.

[0078] Alternative client and / or server version identifiers can be used.

[0079] To improve readability, the examples provided in this article will use incrementing integers, such as (0, 1, 2, ..., n), for the client version identifier and incrementing integer pairs, such as (0-0, 1-1, 2-1, ..., nn), for the server version identifier (recognizing that in some implementations, the first integer of a given server version identifier will actually be a timestamp).

[0080] Communication Protocol

[0081] In this disclosure, CA 120 and CS 110 are configured to connect in a manner that provides a reliable, ordered, full-duplex message flow between them. Any suitable connection protocol that provides this characteristic can be used, such as a TCP connection, a WebSocket connection, or an alternative connection.

[0082] In this disclosure, a message sent from a given CA 120 to an SA 110 will be referred to as a client message, and a message sent from an SA 110 to a given CA 120 will be referred to as a server message.

[0083] connect

[0084] To begin editing a given shared object, CA 120 opens a connection to that shared object via a connection request.

[0085] In this implementation, this involves CA 120 generating a connection message that includes an identifier for a given object, a server version identifier for the object the client application wishes to connect to, and a client version identifier for the object. For example:

[0086] Connect(ObjectId, sv, cv)

[0087] Before opening a streaming connection, the client must have a snapshot (sv, state) corresponding to an entry in the server's canonical history. The client can obtain such a snapshot in various ways, such as by making a dedicated request to the server via another channel (e.g., an HTTP request), or by using a snapshot obtained from a previous edit session of the same object. (sv, state) does not need to be the current or most recent state on the server; any historical state is sufficient.

[0088] CA 120 is configured to initialize the client version identifier to an initial value (e.g., 0) when a client first connects to a given object. As described below, CA 120 updates the client version identifier during a collaborative editing session associated with the object. If CA 120 disconnects from the object and then reconnects, it can use the current value of the object's client version identifier.

[0089] information

[0090] Once a connection is established between CA 120 and an object maintained by SA 110 (e.g., according to the connection message described above), users of CA 120 can view / edit the object. Furthermore, CA 120 can receive editing messages related to other CA 120 objects from SA 110.

[0091] To this end, this disclosure provides four types of information, each of which will be described in turn.

[0092] When CA 120A receives a local edit (i.e., an edit made to an object by a user of CA 120A), CA 120A generates a ClientSubmit message and sends it to SA 110. In this embodiment, the ClientSubmit message includes: a client version identifier (cv), which indicates the version identifier of the client application of the edited object; and an increment (d) describing the edit already made locally. For example:

[0093] ClientSubmit(cv, d)

[0094] When SA 110 edits an object (based on edits received from CA 120 connected to the object), SA 110 generates a ServerSubmit message and transmits it to CA 120 connected to the object. In this embodiment, the ServerSubmit message includes: a server version identifier (sv), which indicates the server application version identifier of the edited object; and an increment (d) describing the edits made. For example:

[0095] ServerSubmit(sv, d)

[0096] Once CA 120A receives one or more ServerSubmit messages, it acknowledges receipt by generating a ClientAck message and sending it to SA 110. In this embodiment, the ClientAck message includes a server version identifier (sv), indicating that CA 120A has received all ServerSubmit messages prior to the server version included in the ClientAck message. For example:

[0097] ClientAck(sv)

[0098] Once SA 110 receives one or more ClientSubmit messages from a given CA 120A, it acknowledges receipt by generating a ServerAck message and sending it to that CA 120A. In this embodiment, the ServerAck message includes a server version identifier (sv) and a client version identifier (cv). The client version identifier in the ServerAck message indicates that SA 110 has received all ClientSubmit messages prior to that client version. The server version identifier in the ServerAck message indicates the server version of the object after processing all ClientSubmit messages prior to that client version. For example:

[0099] ServerAck(sv, cv)

[0100] It is understood that the above message structure allows CA 120 to acknowledge multiple ServerSubmit messages using a single ClientAck message, and allows SA 110 to acknowledge multiple ClientSubmit messages from a given CA using a single ServerAck message.

[0101] Example Communication

[0102] Turning Figure 3 and Figure 4 To provide an overview of the communication protocol, two example message passing diagrams are provided to illustrate the operation of the protocol described above. Further details regarding the operation of server SM 112 and client SM 124 in generating and processing messages are then provided.

[0103] Figure 3 Message transmission example 300 involves a single client application 120A connecting to and editing an object maintained by SA 110. The initial server version identifier (sv) of the object is 0-0.

[0104] In step 302, CA 120A initiates a connection with SA 110 using the connection message: Connect(x, 0-0, 0). This indicates that CA 120A wishes to connect to an object with the identifier x; the object's server version is 0-0; and the object's client version is 0.

[0105] In response to 304, CA 120A receives a local edit made by the user to object x. An increment (d1) representing the edit is generated, and CA 120A increments the client version to 1 (i.e., after applying increment d1, the client version is 1). CA 120A then generates and transmits a client commit message: ClientSubmit(1, d1). This indicates that after applying edit d1, the client version is 1.

[0106] At 306, SA 110 receives the ClientSubmit message red1.

[0107] In step 308, SA 110 applies the increment d1 to the server version of the object. As described below, this typically involves SA110 generating a server increment corresponding to the increment received in the ClientSubmit message. However, since only one client is connected in this example, no transformation is necessary.

[0108] SA 110 application increments result in an update to the server version, which in this example is sv=1-0. (As mentioned above, in this example implementation, the server version is a timestamp and sequence identifier; the timestamp is the time the server saved the increment to the canonical object history.)

[0109] SA 110 then generates and sends ServerAck to CA 120A: ServerAck(1-0, 1). This instructs CA 120A that the server has received all ClientSubmits prior to client version 1 from CA 120A, and applies the increment to these ClientSubmits, bringing the server version of the object to version 1-0.

[0110] Since only one client is connected in Example 300, SA 110 does not need to generate / transmit ServerSubmit messages for the applied increments.

[0111] In 310, CA 120A: Receive another local edit; generate an increment (d2) representing the edit; increment the client version (to 2); generate and send the client commit message: ClientSubmit(2, d2). This indicates that after applying edit d2, the client version is 2.

[0112] At 312, SA 110 receives the ClientSubmit message red2.

[0113] In 314, CA 120A: Receive further local edits; generate an increment (d3) representing the edits; increment the client version (to 3); generate and transmit the client commit message: ClientSubmit(3, d3). This indicates that after applying edit d3, the client version is 3.

[0114] It can be seen that CA 120A generates and transmits ClientSubmit message red3 before receiving any confirmation of ClientSubmit message red2.

[0115] At 316, SA 110 receives the ClientSubmit message red3.

[0116] In 318, SA 110 applies d2 and d3 to the server version of the object, and then, in this example, updates the server version to 2-0. In this case, SA 110 combines the increments d2 and d3 together (as described below) and applies the resulting composition. SA 110 then generates a ServerAck and sends it to CA 120A: ServerAck(2-0, 3). This instructs CA 120A that the server has received all ClientSubmits prior to client version 3 from CA 120A and applies the increments to these ClientSubmits, changing the object's server version to version 2-0.

[0117] Figure 4 Message transmission example 400 involves two client applications 120A and 120B, which connect to and edit an object maintained by SA110. The initial server version identifier (sv) of the object is 0-0.

[0118] In this example, for readability, the client version identifier is prefixed with "A" and "B" (representing CA120A and CA 120B respectively). While such prefixes can be used if needed, they are not required because the SA 110 maintains separate state data for each connected client.

[0119] In 402 and 403, CA 120A and CA 120B initiate a connection to SA 110. In both cases, the connection message is: Connect(y, 0-0, [A / B]0), indicating that the object ID being connected is y; the server version of the object is 0-0; and for both CAs, the local version identifier of the object starts from [A / B]0.

[0120] At 404, CA 120A: Receives local edit; generates an increment representing the edit (Ad1); increments the client version (to A1); generates and sends the client commit message: ClientSubmit(A1, Ad1). This indicates that after applying editAd1, the local version at CA120A is A1.

[0121] At 406, SA 110 receives the ClientSubmit message re Ad1.

[0122] In step 408, SA 110 applies the increment Ad1 to the server version of the object. This typically involves generating a server increment (in this case, Sd1) corresponding to the increment received in the ClientSubmit message. However, since increment AD1 is the first increment transformation, no transformation is required (or the transformation process will end with the same server increment as increment Ad1). Applying the increment results in an updated server version, in this example, sv = 1-0, adding the increment to the object's history as described below.

[0123] SA 110 then generates and sends ServerAck to CA 120A: ServerAck(1-0, A1). This instructs CA 120A that the server has received all ClientSubmits prior to client version A1 from CA 120A, and applies the increment to these ClientSubmits, bringing the server version of the object to version 1-0.

[0124] SA 110 also generates a ServerSubmit message and sends it to all other connected clients, in this case CA 120B: ServerSubmit(1-0, Sd1). This indicates to CA120B that after applying the increment Sd1, the server-local version of the object is 1-0.

[0125] At 410, CA 120B receives the ServerSubmit message re Sd1.

[0126] In step 412, CA 120B applies the increment Sd1 to the local version of its object. As described below, this may involve transforming the increment (in this case, Sd1) received in the ServerSubmit message. CA 120B then generates and transmits a ClientAck message: ClientAck(1-0). When received by SA 110, this indicates that CA 120B has received all ServerSubmit messages prior to server version 1-0.

[0127] At 414, CA 120B: Receives the local edit; generates an increment (Bd1) representing the edit; increments the client version (to B1); generates and sends the client commit message: ClientSubmit(B1, Bd1). This indicates that after applying the edit Bd1, the local version at CA120B is B1.

[0128] At 416, SA 110 receives the ClientSubmit message re increment Bd1.

[0129] In 418, SA 110 applies the increment Bd1 to the server version of the object. As described below, this involves generating a server increment (Sd2 in this case) corresponding to the increment received in the ClientSubmit message. Once the increment is applied, SA 110 updates the server version, which in this example is sv=2-0.

[0130] SA 110 then generates and sends ServerAck to CA 120B: ServerAck(2-0, B1). This instructs CA 120B that the server has received all ClientSubmits prior to client version B1 from CA 120B, and applies the increment in these ClientSubmits to bring the server version of the object to version 2-0.

[0131] SA 110 also generates and sends a ServerSubmit message to CA 120A: ServerSubmit(2-0, Sd2). This instructs CA 120A that the server-local version of the object is 2-0 after the application edits Sd2.

[0132] At 420, CA 120A receives the ServerSubmit message re Sd2.

[0133] At 422, CA 120A applies the increment Sd2 to its local version of the object. As described below, this may involve transforming the increment (in this case, Sd2) received in the ServerSubmit message. CA 120A then generates and transmits a ClientAck message: ClientAck(2-0). When received by SA 110, this indicates that CA 120A has received all ServerSubmit messages prior to server version 2-0.

[0134] Figure 4 The additional local editing of the relevant messages / processing in CA 120B (at 424) and CA 120A (at 434) is described. This is similar to the messages / processing described above.

[0135] Object synchronization

[0136] When CA 120 receives an increment (e.g., in a ServerSubmit message), it must apply the increment to the client-local version of the object. Similarly, when SA 110 receives an increment (e.g., in a ClientSubmit message), it must apply the increment to the server version of the object.

[0137] As described below, in certain circumstances, the CA 120 or SA 110 can combine multiple increments into a single increment (via one or more composition operations) before applying a single increment.

[0138] In most cases, a transformation operation is necessary to apply a given increment. This is to illustrate that the increment received in a commit message may be performed by the sender of the commit message on a version of the object that is different from the current version of the object at the receiver of the commit message.

[0139] The transformation operation is discussed further below. This section describes how the SA 110 and CA 120 manage increments and version numbers. In this implementation, increment management (and synchronization) is handled by the synchronization module (SM).

[0140] First, the operation of the client application SM 124 will be described. Next, the operation of the server application SM 112 will be described.

[0141] Client application synchronization

[0142] Figure 5 It provides interaction between the client synchronization module (SM) 124, the client editor module (EM) 122, and the collaboration server 110.

[0143] During collaborative editing of a specific object, the client SM 124 maintains a client-side incremental buffer 502 for that specific object.

[0144] Local editing in this disclosure is non-blocking. Therefore, when a user of CA 120 edits an object that is being collaboratively edited, EM 122 immediately applies the edit to the local version of that object (i.e., before any ClientSubmit messages are transmitted and / or any ServerAck messages are received).

[0145] During local editing, EM 122 also transmits editing-related data to the client SM 124.

[0146] Then, the client SM 124 generates a local increment related to the edit. In an alternative implementation, EM 122 can generate the increment and send it to the client SM 124.

[0147] Then, the client SM 124 places the increment in the client increment buffer 502. In this embodiment, the client SM 124 marks the increment in the client increment buffer as unacknowledged (i.e., the increment that CA 120 has already transmitted to SA 110 in the ClientSubmit message) or pending (i.e., the increment that CA 120 has not yet transmitted to SA 110).

[0148] Therefore, firstly, the given increment corresponding to the local edit is placed in the client buffer as a pending increment.

[0149] Client SM 124 periodically generates ClientSubmit messages for pending increments in the buffer. Once a ClientSubmit message for a pending increment is sent to SA 110, client SM 124 marks the increment as unacknowledged.

[0150] In this embodiment, the client SM 124 assigns a client version identifier to the increment when generating the ClientSubmit message. That is, when the ClientSubmit message includes an increment, the client SM 124 updates the current version identifier (e.g., by incrementing the current client version variable maintained by the client SM 124) and associates the version identifier with the increment.

[0151] In an alternative embodiment, client SM 124 may be configured to update the client version identifier and assign it to the increment (i.e., as a pending increment) when an increment is added to client buffer 502. However, this may result in the generation / assignment of unnecessary version identifiers, for example, in the case of pending increments in client-side increment buffer 502 in the following combination (composition).

[0152] Client SM 124 can be configured to handle pending increments in client buffer 502 in a variety of ways (by generating ClientSubmit messages). For example, client SM 124 can be configured to implement a sliding window type scheme for generating ClientSubmit messages: that is, allowing a maximum number of unacknowledged increments in the buffer at any given time.

[0153] As an example, if the sliding window (maximum number) is set to 8, the client SM 124 can send a maximum of eight ClientSubmit messages to the CS110 without receiving a ServerAck message. Once a ServerAck message is received, the client SM 124 can send one or more additional ClientSubmit messages.

[0154] Conversely, if the sliding window (maximum number) is set to 1, the client SM 124 can send a single ClientSubmit message to CS 110 before having to wait for the ServerAck message. In some respects, using a window of this size (1) will result in a collaboration platform similar to existing collaboration platforms that require confirmation of each increment before further increments can be sent.

[0155] Additional logic can be implemented to determine the window size of a given client SM 124 (determined by the SM 124 itself and / or SA110). For example, a given client SM 124 can choose to suppress the rate at which it sends ClientSubmit messages, for example, sending one message every 250 milliseconds. A given client SM 124 can also monitor the wait time between its ClientSubmit messages and receiving the corresponding ServerAck acknowledgment, and adjust its sending rate to window size / wait time to aim for a stable, fastest possible submission rate.

[0156] However, generally speaking, a small window size for a given client A means that other clients will observe client A's edit operations in slower and larger blocks of data. A window size of 1 means that the client's edits will eventually be broken down into units no smaller than the round-trip time from the client to the server. A large window size means that client A can commit more granular edits at a faster rate, making other clients observe A's edits more smoothly. However, a potential drawback is that sending commits at a faster rate requires more server processing to keep up with the higher message throughput.

[0157] When client SM 124 receives a ServerAck message from CS 110, it clears all unacknowledged increments from client buffer 502, up to (including) increments associated with the client version identifier indicated in the ServerAck message.

[0158] The client SM 124 can also (at any time) receive a ServerSubmit message containing a server increment (i.e., an increment in which another client edits an object).

[0159] When the ServerSubmit message is received, the client SM 124 processes it.

[0160] In some cases, SM 124 can process the received ServerSubmit message immediately. Initially, this involves determining whether an increment received in the ServerSubmit message needs to be transformed. If there are any increments (pending or unacknowledged) in the client buffer 502, transformation will be required. If not, no transformation is needed.

[0161] If there are one or more increments in the client buffer 502, then the client SM 124 transforms the increments contained in the server commit message for all increments (pending and unacknowledged) in the client buffer. (Increment transformation will be discussed further below).

[0162] The client SM 124 then applies the increment (with transformations if necessary) to the current version (e.g., current state) of the client's object. This involves communicating with EM 122 to make it display the edits to the object caused by the applied increment.

[0163] Once the increment is applied, SM 124 generates a ClientAck message, which includes the server version identifier contained in the ServerSubmit message.

[0164] In other cases, SM 124 may delay processing a ServerSubmit message once it is received. In this case, if additional ServerSubmit messages are received before SM 124 processes the original ServerSubmit message, SM 124 combines the increments included in those ServerSubmit messages to generate a combined server increment.

[0165] SM 124 then determines whether a transformation of the composed server increment is required. As stated above, if there are any increments (pending or unconfirmed) in client buffer 502, a transformation will be required. If not, no transformation is required.

[0166] If there are one or more increments in the client buffer 502, the client SM 124 transforms the composed server increment for all increments (pending and unconfirmed) in the client buffer. The client SM 124 then applies the composed increment (transformed if necessary) to the current version (e.g., current state) of the object at the client.

[0167] When a ServerSubmit message is composed in this manner, once the composition increment is generated and / or applied, SM 124 can generate a ClientAck message, which includes the server version identifier contained in the latest ServerSubmit message.

[0168] The following provides various examples to illustrate the above processing.

[0169] In these examples, each increment generated for local editing is added as a buffer object to the client buffer. The pending buffer object has the following format:

[0170] {Δ}

[0171] Unconfirmed buffer objects have the following format:

[0172] [Δ, x]

[0173] In both cases, Δ is the increment. For unacknowledged buffer objects, x is the client version identifier (an incrementing integer in this example).

[0174] In addition, client-side buffers are maintained as ordered data structures, such as lists, stacks, queues, or other ordered data structures. Therefore, the position of buffered objects within the buffer is important and represents their order.

[0175] Although the above format is used to improve readability, in this embodiment, the relevant aspects of a given buffer object in the buffer are: its order relative to other increments in the buffer can be determined; it can be identified as an increment that is pending or unconfirmed; and for unconfirmed increments, the object allows determination of the client version associated with the increment.

[0176] Client application synchronization: Example 1

[0177] In this example, collaborative editing of the object begins with client version 0 (cv=0) and server version 0-0 (sv=0-0).

[0178] The first local edit (performed on local version 0 of the object) produces the following incremental buffer:

[0179] {Δa}

[0180] That is, a buffer with a single pending increment.

[0181] Then, client SM 124: increments the client version identifier (from 0 to 1); generates a ClientSubmit message (1, Δa) and sends it to SA 110; and modifies the buffer object in the buffer to mark it as an unacknowledged increment, resulting in the following increment buffer:

[0182] [Δa, 1]

[0183] Then, client SM 124 receives a ServerAck message, such as (1-0, 1), indicating that SA 110 has received client messages prior to cv=1. Upon receiving this message, client SM 124 can remove the buffered object [Δa, 1] from the buffer (resulting in an empty buffer in this case).

[0184] Client application synchronization: Example 2

[0185] In this example, collaborative editing of the object begins with client version 0 (cv=0) and server version 0-0 (sv=0-0).

[0186] Furthermore, the first local edit (performed on local version 0 of the object) produces the following incremental buffer:

[0187] {Δa}

[0188] Then, the client SM 124 performs processing to generate a ClientSubmit message (1, Δa) and sends it to SA110 (as described in Example 1 above). This results in the following incremental buffering:

[0189] [Δa, 1]

[0190] Then a second local edit is performed, producing the following incremental buffer:

[0191] [Δa, 1]{Δb}

[0192] Then, a third local edit is performed, resulting in the following incremental buffer:

[0193] [Δa, 1]{Δb}{Δc}

[0194] In this example, client SM 124 performs processing to generate / transmit to SA 110 separate ClientSubmit messages related to the first two pending buffer objects in the buffer: namely ClientSubmit(2, Δb) and ClientSubmit(3, Δc). The resulting incremental buffer is:

[0195] [Δa, 1][Δb, 2][Δc, 3]

[0196] Then, client SM 124 can receive a ServerAck message, for example, (1-0, 2), indicating that SA 110 has received client messages prior to cv=2. Upon receiving this message, client SM 124 can remove buffer objects [Δa, 1] and [Δb, 2] from the buffer, thereby creating a client buffer:

[0197] [Δc, 3]

[0198] (Conversely, if the ServerAck message is (1-0, 3), then the client SM 124 can remove all buffered objects from the buffer, resulting in an empty client buffer.)

[0199] Client application synchronization: Example 3

[0200] In Example 2, a single ServerAck message is used to acknowledge multiple ClientSubmit messages.

[0201] As a more general case, consider a buffer with the following state:

[0202] [Δa,1][Δb,2]...[Δ,i][Δ,j]{Δx}{ΔY}...

[0203] In this scenario, the ServerAck message for (xx, i) is used to acknowledge all unacknowledged client buffer objects in the client buffer, up to and including the buffer object with cv = i, resulting in the following buffer:

[0204] [Δ, j]{Δx}{Δy}...

[0205] Client application synchronization: Example 4

[0206] In Example 2, the following incremental buffer is generated:

[0207] [Δa, 1]{Δb}{Δc}

[0208] In this scenario, instead of generating / transmitting separate ClientSubmit messages for the first two pending buffer objects, the client SM 124 can combine two pending buffer objects into a single buffer object by performing a composition operation on its increment (combining (Δb, Δc) as described below). The client SM 124 then generates a new pending buffer object with a composition increment (denoted as Δbc in this case) and replaces the buffer object that has now been combined with the new buffer object, thus producing an incremental buffer:

[0209] [Δa, 1]{Δbc}

[0210] Client SA124 can generate / transmit a ClientSubmit message on a new buffer object, i.e., ClientSubmit(2, Δbc), thereby creating a client buffer.

[0211] [Δa, 1][Δbc, 2]

[0212] Then, client SM 124 can receive a ServerAck message, for example, (1-0, 2), indicating that SA 110 has received client messages prior to cv=2. Upon receiving this message, client SM 124 can remove buffer objects [Δa, 1] & [Δbc, 2], thereby creating an empty client buffer.

[0213] More generally, the client SM 124 can be configured to combine any number of adjacent pending buffer objects (or adjacent local increments) into a single increment and include that single increment in a single ClientSubmit message. Various methods can be used for this.

[0214] For example, client SM 124 can group local increments together when adding them to the buffer. For instance, a local increment generated when the client buffer has no pending increments is added to the buffer as a pending increment. When the client buffer has pending increments, the generated local increment is grouped with those pending increments, and the grouped increment is then added to the client buffer as a pending increment (replacing the existing pending increment). When this method is used, the client buffer will maintain a single pending increment at any given time.

[0215] Alternatively, the client SM 124 can store new local increments in a temporary list (or other data structure) and then periodically clear the temporary list by assembling all increments in the temporary list into a single increment, and then generating a single ClientSubmit message that includes that single increment. In some cases, this approach, by maintaining and then batching local increments while generating the ClientSubmit message, provides more efficient processing than performing the composition operation continuously as new local increments arrive.

[0216] Client application synchronization: Example 5

[0217] In this example, collaborative editing of objects begins with client version 0 (cv=0) and server version 0-0 (sv=0-0).

[0218] In this example, two local edits are created, and a ClientSubmit message is sent to the first of these edits. This will generate a buffer as follows.

[0219] [ΔCl,1]{ΔC2}

[0220] Then, the client SM 124 receives the ServerSubmit message: ServerSubmit(1-0, ΔS1).

[0221] To process the ServerSubmit message, client SM 124 determines that an increment exists in the client buffer. Therefore, client SM 124 transforms the increment in the ServerSubmit message (ΔS1 in this case) for all increments in the client buffer (ΔC1 & ΔC2 in this case).

[0222] Figure 6 Example state space diagram 600 is provided to represent the three types of editing.

[0223] The state space diagram used in this disclosure (e.g., Figure 6 , Figure 7 , Figure 9 and Figure 10Solid boxes represent actual object states (i.e., object states generated by applying increments); solid arrows connecting two object states represent increments that have been applied to one object state (the state at the start of the arrow) to generate another object state (the state at the end of the arrow); dashed boxes represent potential object states (i.e., object states that can be generated by applying increments); dashed arrows connecting two object states represent increments that can be applied to one object state (the state at the start of the arrow) to generate another object state (the state at the end of the arrow).

[0224] State 602 in state space 600 represents the initial state of the object (sv = 0-0, cv = 0). At this point, the client and server versions of the object are synchronized (i.e., sv0-0 = cv0).

[0225] From state 602, CA 120 local application increment ΔC1 transitions the object's client state to state 604 (cv=1). From state 604, CA 120 local application increment ΔC2 transitions the object's client state to state 606 (cv=2).

[0226] At the same time, SA 110 applies the increment ΔS1 (received from another client) to transition the object's server state to state 608 (sv = 1-0).

[0227] As shown in state space diagram 620, in order to apply the increment ΔS1, the client application SM 124 first needs to transform the local increment.

[0228] Therefore, the client SM 124 can, for example, perform a transformation operation on (ΔC1, ΔS1) to generate (ΔC1', ΔS1'); and then perform a transformation operation on (ΔC2, ΔS1') to generate (ΔC2', ΔS1").

[0229] Then, the client SM 124 can apply the increment ΔS1” to the local version of the object (i.e., state 606).

[0230] Then, the client SM 124 generates / transmits a ClientAck message indicating the current server version (e.g., ClientAck(1-0)).

[0231] At this point, if no further editing is performed, once the server SA 110 receives / transforms / applies the client's local edits ΔC1 and ΔC2, the client and server versions of the object will be synchronized.

[0232] Client application synchronization: Example 6

[0233] In Example 5 above, the client's SM 124 receives the ServerSubmit message (ServerSubmit(1-0, ΔS1)) when the buffer is in the following state.

[0234] [ΔC1, 1]{ΔC2}

[0235] In Example 5, the ServerSubmit message is processed by performing two transformation operations to (finally) generate ΔS1", which is then applied to the client version of the object.

[0236] However, as described below, this disclosure provides composition and transformation functions that satisfy the transformation / composition exchange property. To illustrate this, instead of performing the two transformation operations as described in Example 5 above, the transformation / composition exchange property will allow client SM 124 to: perform composition on two local client increments (e.g., composition (ΔC1, ΔC2)) to generate a single increment ΔC(1, 2)); transform this single increment for server increments (e.g., transformation (ΔC(1, 2), ΔS1) = (ΔC(1, 2)', ΔS1)"); and then apply the transformed server increment (ΔS1") to the current local state of the object.

[0237] Figure 7 The state space diagram 700 provides an example.

[0238] Once the client SM 124 changes and applies the server increment, the client SM 124 generates / transmits a ClientAck message indicating the current server version (e.g., ClientAck(1-0)).

[0239] At this point, if no further editing is performed, once the server SA 110 receives / transforms / applies the client's local edits ΔC1 and ΔC2, the client and server versions of the object will be synchronized.

[0240] While this specific example is used to illustrate the transformation / composition exchange feature, it is unlikely that the client SM 124 would be configured to compose multiple client increments from the client increment buffer during the processing of server increments received in a server commit message. Even if it were to do so, the client SM 124 would need to retain each increment in the client increment buffer, at least for the purpose of acknowledgment and client reconnection (discussed further below).

[0241] More practically, the transform / compose exchange feature allows transforming the increments generated by composition to generate transformed increments for client increments by composing a sequence of server increments, and then applying the transformed server increments to the current local (client) state of the object, transforming client increments (unacknowledged or pending) for any length of server increment sequence (received in the ServerSubmit message).

[0242] For example, consider a client SM 124 buffer with the following state:

[0243] [ΔC1, 1]

[0244] And receive three ServerSubmit message sequences:

[0245] ServerSubmit(1-0, ΔS1)

[0246] ServerSubmit(2-0, ΔS2)

[0247] ServerSubmit(3-0, ΔS3)

[0248] In this scenario, the client SM 124 can apply the server increment in the ServerSubmit message in the following way:

[0249] Perform incremental execution on all servers, for example:

[0250] Composition (ΔS1, (Composition (ΔS2, ΔS3))) = Composition server increment ΔS(1, 2, 3)

[0251] For example, server incremental transformation client incremental transformation:

[0252] Transformation (ΔC1, ΔS(1, 2, 3)) = (ΔC1′, ΔS(1, 2, 3)′)

[0253] The transformed server increment (ΔS(1,2,3)′) is applied to the current object state on the client.

[0254] In this example, server increments for a given CA 120 are accumulated, grouped together, and then transformed for client increments in a similar manner to that described above.

[0255] More generally, when a client has N unacknowledged ClientSubmit messages and receives M ServerSubmit messages, it faces the following situation: Figure 11The scenario shown illustrates this. In this case, instead of performing N×M transformations, the transformation / composition exchange feature allows the client to combine M increments from the ServerSubmit message into a single increment, and then perform only N transformations (similar to...). Figure 6 (Scenario 620). Doing so will cause the client to execute N+M units of work instead of NxM units of work.

[0256] This situation is symmetrical in server-side processing. For example, the server can combine the increments of N received ClientSubmit messages into a single increment, and then perform M transformations, with each increment of the M unacknowledged ServerSubmit messages undergoing one transformation.

[0257] Server application synchronization

[0258] Server application synchronization is similar to client application synchronization in many ways. However, there are also differences.

[0259] For server application synchronization, message processing is, in a sense, the opposite of client application synchronization. For example, server SM 112 processes ClientSubmit messages in a similar way to how client SM 124 processes server commit messages.

[0260] Of course, another difference is that the SA 110 can receive ClientSubmit / ClientAck messages from many clients (unlike the CA 120, which receives ServerSubmit / ServerAck messages from a single server).

[0261] To solve this problem, such as Figure 8 As shown, server SM 112 provides a synchronizer 802 for each client connected to the object, and each synchronizer 802 maintains a server-side incremental buffer for its client. In the example shown, two clients 120A and 120B are connected to these objects. Therefore, server SM 112 provides: a synchronizer 802A and a server-side client buffer 804A for client 120A, and a synchronizer 802B and a server-side client buffer 804B for client 120B.

[0262] When SA 110 receives an incoming message (e.g., a ClientSubmit or ClientAck message), the server first identifies the originating CA 120: that is, the connection CA 120 from which the message originated. This initiating client can be determined, for example, by referring to the communication protocol data associated with the CA 120 / SA 110 connection and / or other metadata associated with the client-initiated message. The initiating client is used to determine which synchronizer 802 will process the incoming message.

[0263] In the case of a ClientAck message, the relevant synchronizer 802 processes the message in a manner similar to how the client SM 124 processes ServerAck messages (as described above). For example, by deleting objects from the client's server-side buffer until / including objects associated with the server version contained in the ClientAck message.

[0264] In the case of a ClientSubmit message, the relevant synchronizer 802 processes the message in a manner similar to how the client SM 124 processes ServerSubmit messages (as described above). For example, synchronizer 802 determines whether the increment in the ClientSubmit message needs to be transformed (if any pending or unacknowledged increments exist in the relevant server-side client buffer 804), and transforms it if necessary. Furthermore, the synchronizer ensures that the increment is stored in the canonical object history 806 (within the object history item, as further described below).

[0265] Standardized Object History

[0266] As mentioned above, SA 110 maintains the canonical object history for each object managed by SA 110. Various mechanisms are possible for maintaining the canonical object history of a given object.

[0267] In general, object history can be implemented with various characteristics, including being append-only and being observable by all connected clients.

[0268] Object history also supports locking: if concurrent operations are received, only one operation can succeed. In some implementations, optimistic locking can be implemented. In this case, if the commit fails, the client can resynchronize with the server version using the object history. Alternative implementations can provide pessimistic locking.

[0269] In one implementation, Redis streams can be used to maintain the canonical history of a given object.

[0270] In this embodiment, the canonical object history is maintained by server SM 112 (e.g., history 806). In an alternative implementation, the object history may be maintained by a separate module / application that communicates with server SM 112.

[0271] As described below, synchronizer 802 is configured to add object history entries corresponding to client increments (i.e., increments received in ClientSubmit messages), which are processed into object history. In this embodiment, each object history entry includes an increment (i.e., the increment involved in the entry) and a server version identifier (indicating the server version after the increment was applied). Object history entries may also include a client identifier (indicating the specific CA (or user account) from which the increment originated) and a client version identifier (taken from the ClientSubmit message that caused the object history entry to be generated). For example:

[0272] [sv, Δ, client_id, cV]

[0273] In some implementations, including a client identifier and a client version identifier in the object history item is optional. For example, this allows server system 102 to inject edits (i.e., incremental ones) that do not originate from any connected CA120, and thus results in object history items without a client ID or client version identifier.

[0274] Each synchronizer 802 is also configured to access the object history and process all items added to it sequentially over time.

[0275] When the synchronizer processes an item in the object history, it first determines whether the item's client_id indicates that the item involves an increment originating from the synchronizer's own client or a different client. For example, if the object history item has client ID 120A, and the synchronizer 802 is associated with client 120A, then the item is associated with the synchronizer's own client.

[0276] If an item is associated with the synchronizer's own client, the synchronizer 802 generates a ServerAck message based on the item and sends the ServerAck message to its client. Then, the synchronizer processes the object history item, and can proceed to the next object history item.

[0277] If the item is associated with another client (identified via an alternative client_id) or not associated with a client (identified in this case due to the lack of a client_id), the increment in the item does not originate from the synchronizer's client. In this case, synchronizer 802 generates a ServerSubmit message based on the item. The ServerSubmit message includes the item's increment and the server version identifier. The object history item is then processed, and the synchronizer can proceed to the next object history item.

[0278] Once all synchronizers 802 have processed all items in the object history 806 (and all clients have processed the resulting ServerSubmit messages), the object is synchronized: that is, the object's state at SA 110 is the same as the object's local state at all connected CA120s.

[0279] If CA 120 is disconnected from SA 110, CA 120 can be reconnected.

[0280] To this end, CA 120 generates and transmits a connection message, with its client version identifier value preceding any unacknowledged client version value submitted by the client in its buffer.

[0281] The CA 120 then retransmits the ClientSubmit message for each unacknowledged increment in its buffer. When retransmitting the ClientSubmit message for a given unacknowledged increment, the CA 120 uses the same client version identifier as the one originally used in the ClientSubmit message generated / transmitted to the server for that increment. However, if a transformation has occurred during this period, the increment may differ.

[0282] To facilitate reconnection in this manner, ClientSubmit messages are idempotently processed by the client synchronizer 802 in the server synchronization module 112. This allows the client to safely resend any ClientSubmit message without requiring SSM 112 to apply any increments twice.

[0283] To this end, SSM 112 maintains the client state table with the same persistence as canonical object history (e.g., Redis Data Store) that tracks the latest client version for each client. If an object is identified by 'x', the client state can be recorded as follows:

[0284] ClientState(x, client_id, client version identifier)

[0285] Each transaction executed by the client synchronizer to add increments to the object history also ensures that its client version matches the latest client version in the ClientState table and updates it (transactionally) to the client version of the entry added to the object history. This transaction can be executed optimistically or pessimistically (although in the case of using Redis data store, this is optimistic because Redis supports such transactions).

[0286] When client synchronizer 802 processes ClientSubmit(cv, d) to add an entry to the object history by executing the transaction, it checks the client ID of the client state entry. If client synchronizer 802 determines that the cv of the ClientSubmit message is not greater than the client version recorded in the last record in the ClientState table, it can simply ignore the ClientSubmit message (in this case, the ClientSubmit message is interpreted as a message that has already been resubmitted).

[0287] In some implementations, the client synchronizer 802 is configured to perform additional steps to verify that such a ClientSubmit message has been received. This involves finding previously received ClientSubmit messages in the canonical object history (i.e., messages with the same client version identifier as the message being processed) and checking if the increment is "same" (after any necessary transformations).

[0288] The data stored in object history 806 allows any CA 120 to resynchronize its local version of its objects with the server version, for example, in the event that CA 120 is disconnected from SA 110, a message error occurs, or other problems arise.

[0289] The following describes server-side processing examples for each message type.

[0290] Server application synchronization: ClientSubmit message

[0291] Upon receiving a ClientSubmit message, server SM 112 first determines which CA 120 the message originated from, and thus determines which synchronizer 802 will process it. In this example, the ClientSubmit message originated from CA 120A, therefore, the message (or related data from it) is transmitted to synchronizer 802A.

[0292] Synchronizer 802A then determines whether the increment in the ClientSubmit message needs to be transformed. If there is no increment in the server-side buffer 804A of the client 120A, then the increment does not need to be transformed. Otherwise, the increment does need to be transformed, and synchronizer 802A performs this transformation (e.g., as described in Client Application Synchronization: Example 5 or Client Application Synchronization: Example 6 above).

[0293] Synchronizer 802A then creates an object history entry for the increment and saves it to object history 806. The object history entry includes the client 120A's identifier, the client version identifier, the transformed increment, and the server version identifier (in the current case, generated by a tool (Redis) used to maintain the object history as object items are added). For example:

[0294] [12345-1, Δx, 120A, A1]

[0295] Similar to the operation of client SM 124 described above, client synchronizer 802A may delay processing received ClientSubmit messages instead of immediately attempting to transform the increments in the client submit messages and add them to object history 806. In this case, if additional ClientSubmit messages are received before synchronizer 802A processes the original ClientSubmit message, synchronizer 802A combines the increments included in those ClientSubmit messages to generate a combined client increment. Synchronizer 802A then transforms the combined client increment for any increments (pending or unacknowledged) in server-side client buffer 804A and any related increments in object history 806 before adding the generated (single) increment to object history item object history 806. In this case, the client version of the object history item is set to the latest client version identifier of the ClientSubmit message whose increments have been combined.

[0296] Before adding the incremental ClientSubmit message (with transformations if necessary) to the object history, synchronizer 802A ensures that the server-side incremental buffer 804A has caught up with the latest history (some of which may not have been processed by synchronizer 802A yet, depending on the object history items stored in object history 806).

[0297] Therefore, two transformation processes are performed. In the first transformation, the increment of ClientSubmit is transformed to exceed the increment currently in the server-side increment buffer 804A of the synchronizer (which may be lagging in persistence from the committed object history). This transfer occurs outside of any transaction with object history 806, and can therefore be performed in parallel by any synchronizer that might attempt to commit increments to the object history. Once the increment from the ClientSubmit message is up-to-date relative to the server-side increment buffer 804A (i.e., has already been transformed for the increments therein), the second transformation process is performed. In the second transformation, the object history transaction is initiated. At this point, any additional entries in object history 806 are detected, and, if necessary, the increment of ClientSubmit is further transformed for the increments of such additional entries. The transformation / composition exchange feature discussed above provides the ability to handle increments from client-submit messages in this way: a first transformation process that transforms the ClientSubmit increment for the increments in the server-side increment buffer 804A, and a second transformation process that further transforms the increments (if necessary) for the increments in any relevant object history items.

[0298] The client synchronizer 802A can be configured to perform a single pass. However, this approach is inefficient in many cases because it increases the time transactions are open. If the single pass method is implemented, a single pass involves opening a transaction, querying for any additional historical items not yet displayed in the server-side buffer 802A, and then transforming the ClientSubmit for all server-side buffer increments and the composition of all additional historical items. In this case, any additional historical items read as part of the transaction are discarded when the transaction is committed. They are not added to the server-side buffer 804A at this time. Instead, they appear in the server-side buffer 804A at the appropriate time via subscriptions that normally populate the buffer.

[0299] Then, the ClientSubmit message processing is complete.

[0300] Server application synchronization: ServerAck message

[0301] When the synchronizer 804A processes an item in the object history 806 at the appropriate time, it will encounter that item (i.e., [12345-1, Δx, 120A, A1]).

[0302] When processing a project, synchronizer 802A first analyzes the client identifier in the project to determine whether the project originated from its own client. In this case, client identifier 120A is the client associated with synchronizer 804A.

[0303] Upon determining this, synchronizer 804A generates a ServerAck message, which includes the server version identifier of the project and the associated client version identifier (obtained from the object's historical project).

[0304] Synchronizer 804A then sends a ServerAck message to its client application CA 120A.

[0305] Processing of the item from object history 806 is complete.

[0306] Server application synchronization: ServerSubmit message

[0307] Synchronizer 802B also processes items from object history 806 and encounters the example items mentioned above when appropriate:

[0308] [12345-1, Δx, 120A]

[0309] When processing this project, synchronizer 802B first analyzes the client identifier in the project to determine if the project originated from its own client. In this case, client identifier 120A is not a client associated with synchronizer 804B.

[0310] Therefore, synchronizer 802B creates a buffer object and adds it to the server-side incremental buffer 802B. The buffer object is based on this item and is created in a manner similar to how the client SM 124 creates buffer objects when performing local client editing. However, the buffer object in server synchronizer 802B includes a server version identifier. For example, processing the above item generates a buffer object as follows (initially pending):

[0311] {Δx, 120A}

[0312] Then, synchronizer 806 processes items in the server-side buffer in a manner similar to how client-side SM 124 processes client-side buffers. For example, synchronizer 802 can combine multiple pending buffer objects in a given client's server-side incremental buffer 804 into a single (combined) buffer object. (See Client Application Synchronization: Example 4 above.)

[0313] When appropriate, synchronizer 802B will generate a ServerSubmit message based on the aforementioned buffer object and send it to client 120B. In doing so, synchronizer 802B updates the buffer object to reflect that it is now an unacknowledged buffer object.

[0314] [Δx, 120A]

[0315] Furthermore, similar to client SM 124, synchronizer 802 can be configured to define the maximum number of unacknowledged buffered objects in the buffer. Synchronizer 802 can be configured to dynamically set the maximum number for its specific clients. In doing so, synchronizer 802 effectively suppresses ServerSubmit messages to its clients. For example, if synchronizer 802A determines that its client 120A is taking too long to acknowledge ServerSubmit messages, it can reduce the window size (i.e., the maximum number of unacknowledged ServerSubmit messages allowed) or even disconnect its client. Conversely, if synchronizer 802B determines that its client 120B is responding quickly to ServerSubmit messages, it can increase the window size.

[0316] Server application synchronization: ClientAck message

[0317] During operation, server SA112 will receive ClientAck messages (each message includes a server version identifier).

[0318] When a ClientAck message is received, server SA112 first determines the originating CA 120 of the message and accordingly determines the relevant synchronizer 802.

[0319] Synchronizer 802 then clears the client's server-side incremental buffer 804 up to (including) the buffer object associated with the server version indicated in the ClientAck message.

[0320] The aforementioned communication protocol (and the operational transformation processing described herein) allows for the merging of message sequences. In other words, a given CA 120 (or SA 110) can send multiple commit messages without waiting for any acknowledgments. Subsequently, CA 120 can acknowledge several ServerSubmit messages with a single ClientAck message, and SA 110 can acknowledge several ClientSubmit messages from a given CA with a single ServerAck message.

[0321] By providing a platform, client or server applications can send multiple commits at once, rather than being forced to send them one at a time, offering a "smoother" or "less jittery" user experience. To illustrate this, consider the following two examples of editing shown by CA 120 (each line in the examples indicates a status change / new edit):

[0322]

[0323]

[0324] As can be seen, in version 1, the user initially sees a small edit, then a delay, then a large cluster edit, then another delay, and then another large cluster edit. The delay between "T" and "The quick b" represents the round-trip time from the client to the server.

[0325] In version 2, users will see a series of small edits. If the window size (as mentioned earlier) is large enough, the intervals between these edits seen by other clients will not be limited by the round-trip time from the authoring client to the server.

[0326] Furthermore, multiple commits are allowed simultaneously, and commit messages can be buffered / queued arbitrarily during transmission (by SA 110 or CA 120, or even proxies). Consecutively buffered / queued messages can be merged into a single message before transformation, thus achieving synchronization more efficiently than protocols requiring acknowledgment of each individual commit. This also allows for an architecture where multiple client applications 120 can be multiplexed through a single proxy machine. The single proxy machine can be configured to impose its own flow control on the messages it receives. For example, such a proxy can be configured to implement maximum throughput or minimum latency by delaying, buffering, and grouping adjacent commit or acknowledgment messages.

[0327] Electronic objects, increments, and increment operations

[0328] In some embodiments, the state of an entity and its evolution over time are described by a so-called domain. In some aspects, the domains of this disclosure are analogous to categories in categorical theory.

[0329] The domain disclosed herein describes the possible state space of an entity, and for this purpose can be viewed similarly to a data type (e.g., a Boolean value or a list of numbers). However, unlike a data type, a domain also describes how an entity in the domain evolves from one state to another. The evolutionary step from one state to another is called an increment. Therefore, a domain describes both the static aspects (i.e., states) and the dynamic aspects (i.e., increments) of an editable entity.

[0330] In the following description, Haskell typeclass syntax is used to render fields.

[0331] Formally, a field is parameterized by a data type representing the state S and a data type representing the increment D. In this implementation, each field defines five functions on its state data type and increment data type: identity, application, deapplication, composition, and transformation. In the Haskell typeclass syntax, "s" is the state data type and "d" is the delta data type, and these functions can be represented as follows:

[0332]

[0333] In addition to these functions (in the strict Haskell method), functional dependencies |s->d, d->s are also required.

[0334] The identity function takes a state as input and generates an increment (which will be called the identity increment). The essence of the identity increment is applying the identity increment to the input state (using the application function described below) and returning the same state.

[0335] The application function takes the state and increment as input and generates the state, that is, the state produced by applying the input increment to the input state.

[0336] The deapplication function is the opposite of the application function. Accordingly, the deapplication function also takes the state and increment as input and outputs the state, in this case, the result of deapplication (or undoing) the input increment on the input state.

[0337] The composition function takes two consecutive increments as input and generates a single increment, which is the composition of the two input increments.

[0338] The transformation function takes a pair of divergent increments as input and generates a pair of convergent increments, which is the operational transformation.

[0339] The domain function described above is characterized by the following relationship:

[0340]

[0341] Domain function relations

[0342] Transformation / Composition Exchange

[0343] In order to provide more efficient collaborative editing, the inventors recognized that it was advantageous to design / provide composition and transformation functions that would satisfy what would be called transformation / composition exchange properties.

[0344] The transform / composition commutative property establishes an equivalence between performing a composition operation after a series of transform operations and performing a single transform operation after a series of composition operations. In other words, transforming before composing is equivalent to composing before transforming (i.e., composition and transform are commutative).

[0345] When a domain satisfies the transformation / composition exchange property, the protocol can leverage this property to efficiently synchronize data between the client and server. An example of such a protocol has been described above; however, alternative protocols are also possible.

[0346] Synchronization examples: single server incremental, continuous client incremental

[0347] Reference Figure 9 State space diagrams 900, 920, and 940 provide examples.

[0348] This example begins with a client application (e.g., CA 120A) and SA110 synchronizing in state 902 for a specific object. Starting in state 902, CA 120A applies a series of increments: Δc1 followed by Δc2, which transitions the client-native version of the object to states 904 and 906, respectively (assuming Δc1 and Δc2 are applied sequentially and not combined into a single increment applied subsequently). Simultaneously, server 110 receives an increment (Δs1) from another client application (e.g., CA 120B) and applies it to the server version of the object, transitioning the server version of the object to state 908.

[0349] Results: When processing increments Δc1 and Δc2 in SA 110, increment Δs1 has already been processed; when processing increment Δs1 in CS120A, increments Δc1 and Δc2 have already been processed.

[0350] As shown in state space diagram 920, in order to handle the increment Δs1, the conventional approach is to perform the following transformations using CA 120A and / or SA 110:

[0351] Transformation 1: (Δc1, Δs1) => (Δc1', Δs1')

[0352] Transformation 2: (Δc2, Δs1') => (Δc2', Δs1”)

[0353] On the client side, the CA 120A can apply the increment Δs1” to state 906 to generate state 912. In this case, the CA 120A performs the following operations:

[0354] <![CDATA[transform (Δc1, Δs1)]]> <![CDATA[generate (Δc1', Δs1')]]> <![CDATA[Transform (Δc2, Δs1')]]> <![CDATA[Generate (Δc2', Δs1")]]> <![CDATA[application 906Δs1"]]> Transition from state 906 to state 912

[0355] On the server side, SA 110 can apply increment Δc1' to state 908 to generate state 910, and apply increment Δc2' to state 910 to generate state 912. The operation performed by SA 110 in this case is as follows:

[0356] <![CDATA[Transform (Δc1, Δs1)]]> <![CDATA[generate (Δc1', Δs1')]]> Transformation <![CDATA[generate (Δc2', Δs1")]]> <![CDATA[apply 908Δc1']]> Transition from state 908 to state 910 <![CDATA[application 910 Δc2']]> Transition from state 910 to state 912

[0357] Alternatively, SA 110 can perform composition operations on Δc1' and Δc2' and apply the resulting increment to intermediate state 908, instead of applying Δc1' and Δc2' sequentially. In this case, the server performs the following operations:

[0358] <![CDATA[transform (Δc1, Δs1)]]> <![CDATA[Generate transformed increments (Δc1', Δs1')]]> <![CDATA[Transform (Δc2, Δs1')]]> <![CDATA[Generate transformed increments (Δc2', Δs1")]]> <![CDATA[composing Δc1'Δc2']]> <![CDATA[Generating a single increment (Δ(c1', Δc2'))]]> <![CDATA[Applying 908Δ(c1', Δc2')]]> Transition from state 908 to state 912

[0359] Typically, algorithms supporting transformation and composition operations have complexity that is linearly proportional to the size of their inputs. That is, the transformation (Δc, Δs) is O(c+s), and the composition (Δc1, Δc2) is O(c+s). i +c2). Therefore, for a client increment sequence of length n, this synchronization method results in an overall complexity of O(n(s+c)).

[0360] However, by providing composition and transformation functions that satisfy the transformation / composition exchange property, client synchronization in this example can be achieved in a single transformation step. This requires that the transformation and composition functions make the update paths described in state space 920 and above equivalent to the update paths described in state space 940, i.e., make the following two operation sequences equivalent:

[0361] <![CDATA[Transform (Δc1, Δs1) = (Δc1', Δs1')]]> <![CDATA[Component (Δc1, Δc2) = Δ(c1, c2)]]> <![CDATA[transform (Δc2, Δs1') = (Δc2', Δs1'')]]> <![CDATA[Transform(Δ(c1, c2), Δs1)=(Δ(c1, c2)', Δs1'')]]> <![CDATA[Applying 906Δs1"=912]]> <![CDATA[Application 906Δs1"=912]]>

[0362] This allows for more computationally efficient synchronization. Specifically, for a client increment sequence of length n, the improved process has a complexity of O(s+nc) (compared to the previous process's complexity of O(ns+nc)).

[0363] Although this example describes a sequence of two client increments for a single server increment transformation, the same principle applies to sequences of any number of client increments that require a single server increment transformation.

[0364] Synchronization examples: continuous server increments, single client increments

[0365] The above text is about Figure 9 The example described involves a single server update and multiple consecutive client updates. The same principle applies to both single client updates and multiple server updates. Figure 10 State space diagrams 1000, 1020, and 1040 describe this situation.

[0366] exist Figure 10 In the example, SA 110 applies two Δs1 and Δs2, while a specific CA 120 (e.g., CA 120A) applies a single incremental Δc1.

[0367] To resynchronize objects, the standard method in SA 110 is to perform the following transformations:

[0368] Transformation 1: (Δs1, Δc1) => (Δs1', Δc1')

[0369] Transformation 2: (Δs2, Δc1') => (Δs2', Δc1”)

[0370] SA 110 can then apply the increment Δc1” to state 1006 to generate state 1012 (as shown in state space diagram 1020). The operation performed by SA 110 in this case is as follows:

[0371] <![CDATA[transform (Δs1, Δc1)]]> <![CDATA[Generate (Δs1', Δc1')]]> <![CDATA[Transform (Δs2, Δc1')]]> <![CDATA[Generate (Δs2', Δc1'')]]> <![CDATA[Apply 1006Δc1"]]> Transition from state 1006 to state 1012

[0372] However, according to this disclosure, server synchronization in this case can be achieved through a single transformation step as follows:

[0373] <![CDATA[composition (Δs1, Δs2)]]> <![CDATA[Generate Δ(s1, s2)]]> <![CDATA[Transform (Δ(s1, s2), Δc1)]]> <![CDATA[Generate (Δ(s1, s2)', Δc1")]]> <![CDATA[Apply 1006Δc1"]]> Transition from state 1006 to state 1012

[0374] As mentioned above, although this example describes a sequence of two server increments that are transformed for a single client increment, the same principle applies to any sequence of server increments that need to be transformed for a single client increment.

[0375] The efficiency provided in this disclosure is significantly greater when parsing client incremental sequences against server incremental sequences. For a client incremental sequence of length n and a server incremental sequence of length m, conventional synchronization methods employ O(mn(s+c)). In contrast, the transformation / composition exchange properties described herein offer a complexity of O(ms+nc).

[0376] More specifically, by leveraging the transform / composition exchange property, the cost of operation transformation (OT) based synchronization protocols is reduced by transforming quadratic operations in the absence of transform / composition exchange property into linear operations.

[0377] refer to Figure 11 and Figure 12 The state-space diagram further illustrates this disclosure. Figure 11 and Figure 12 The state space diagram is shown, in which the client performs three local edits (Δc1 to Δc3), while the server performs three server edits (Δs1 to Δs3).

[0378] Figure 11 The required transformation is described in the absence of transform / composition exchange features. In this case, for synchronization, the client can:

[0379] Transformation (Δc1, Δs1) = (Δc1', Δs1')

[0380] Transformation (Δc2, Δs1') = (Δc2', Δs1”)

[0381] Transformation (Δc3, Δs1”) = (Δc3', Δs1”')

[0382] Application (state 1108, Δs1”') = state 1120

[0383] Transformation (Δc1', Δs2) = (Δc1", Δs2')

[0384] Transformation (Δc2', Δs2') = (Δc2", Δs2")

[0385] Transform (Δc3', Δs2”) = (Δc3”, Δs2”')

[0386] Application (state 1120, Δs2”') = state 1122

[0387] Transformation (Δc1”, Δs3) = (Δc1”', Δs3’)

[0388] Transformation (Δc2”, Δs3’) = (Δc2”’, Δs3”)

[0389] Transformation (Δc3”, Δs3”) = (Δc3”', Δs3”')

[0390] Application (state 1122, Δs3”') = state 1124

[0391] The server needs to perform a similar set of operations.

[0392] In comparison, Figure 12 It describes the transformations that can be used when there are transformation / composition exchange properties.

[0393] In this case, the client can:

[0394] Composition (Δc1, (composition (Δc2, Δc3)) = Δc 123

[0395] Composition (Δs1, (composition (Δs2, Δs3)) = Δs 123

[0396] Transformation (Δc) 123 Δs 123 )=(Δc 123 ',Δs 123 ')

[0397] Application (state 1108, Δs) 123 ') = State 1124

[0398] The server performs a similar operation, and then:

[0399] Application (state 1114, Δc) 123 ') = State 1124

[0400] Example domain

[0401] This section provides example domains designed to satisfy the above transformation / composition exchange properties.

[0402] The described domains can be used as component domains; that is, they can be combined in various ways to express a variety of specialized data schemas. Any schema expressed using these domains inherits the aforementioned synchronization efficiency.

[0403] For clarity and brevity, the example algorithm implementations for each domain are presented in Haskell syntax.

[0404] Primitive Domain

[0405] Cell domain

[0406] A unit domain is a degenerate domain. It has a single state and a single way of evolving that state: doing nothing.

[0407] In Haskell, a cell field can be represented as follows:

[0408]

[0409] Such a cell field can be used to test objects.

[0410] constant field

[0411] The constant field is a field with arbitrary states, but only allows identical increments. That is, the value cannot evolve from one state to another.

[0412] In Haskell, the constant field can be represented as follows:

[0413]

[0414] Constant fields are used to describe values ​​that cannot be changed. In collaborative data models, some elements can be assigned immutable identifiers. For example, in a document editor, each page might be assigned a UUID. The page's UUID should not change. Representing a page's identifier as a constant field allows its value (UUID) and its immutability (no increments to change it) to be represented in this field style.

[0415] Counter domain

[0416] The counter field represents a number that evolves only by increment. The state of the counter can be represented as Int. The increment of the counter (i.e., the increment value) can also be represented as Int.

[0417] In Haskell, a counter field can be represented as follows:

[0418]

[0419] Similar to cell fields, counter fields can be used to test objects.

[0420] Higher-order domain

[0421] Higher-order fields are generated from other fields, for example, when a higher-order data type generates a new data type from an existing data type.

[0422] Pairing and Product Domain

[0423] The pairing field and the product field are higher-order fields (in a sense, they are new fields generated from existing fields, just as higher-order data types generate new data types from existing data types).

[0424] The pairing domains take two domains, A and B, and produce domains representing entity pairs: one from domain A and one from domain B. The pairing evolves from the increments of the original domain pairs: one increment from domain A and one increment from domain B. The state and increments of the paired entities are both represented using the pairing type (_, _).

[0425] In Haskell, a pairing field can be represented as follows:

[0426]

[0427] The product domain is a generalization of the paired domains of any set of component domains.

[0428] For example, the product of domains A, B, C, and D represents an entity tuple: one from domain A, one from domain B, one from domain C, and one from domain D. The product domain can be generalized from the paired domains by distributing the domain functions (identity, apply, unapply, ...) across all components in the same manner as the paired domains.

[0429] For example, when expressed in languages ​​such as Java or JavaScript, a "tuple" of the product domain can be represented as a map object (dictionary).

[0430] For example, in a collaborative presentation application environment, a content field might be defined as the product of the following: Boxes with "title" as the keyword. <string>The `<page>` field; and the `<page>` field (the description box and list field below) containing the keyword "page".

[0431] Any summation field

[0432] Any domain takes two domains, A and B, and produces a domain representing the separate "any" in an entity: one from domain A and one from domain B. "Any" is derived from an increment from the original domain A or an increment from the original domain B. The state and increments of any entity are represented using the Any type.

[0433] In Haskell, any field can be represented as follows:

[0434]

[0435] The domain of summation is the induction of any domain into any number of domains. For example, the sum of domains A, B, C, and D represents the union of entities: one from domain A, one from domain B, one from domain C, or one from domain D. The domain of summation can be inductively derived from any domain.

[0436] For example, in the context of collaborative design applications, design elements may be one of a few element "types," such as "image" elements, "shape" elements, or "text" elements. For a given ImageElement, ShapeElement, and TextElement field, this can be represented as an element field that is a summation of the following fields: the ImageElement field labeled "image"; the ShapeElement field labeled "shape"; and the TextElement field labeled "text."

[0437] When modeled in this way, objects in an element field can be one of those specific element types, but cannot evolve from one type to another: they retain their type during their use.

[0438] frame

[0439] A box domain transforms any existing domain into another by adding lifecycle semantics to its state. A box entity can evolve in either way: through an update from its original domain; or by being replaced (re-instantiated) by any state from its original domain.

[0440] In Haskell, a box field can be represented as follows:

[0441]

[0442] For example, in a collaborative design application environment, a page might have a "background" property whose pattern is described by the product field, cropping box, and transparency value of an image. This representation allows for simultaneous and independent editing of different aspects of the page background, such as the cropping box and transparency. Representing this pattern as a box of the product field (rather than directly representing the product field) expands the possible set of edits, including not only individual edits of specific aspects of the background (e.g., changes in transparency) (as an update) but also edits that automatically replace the entire background with specifically specified edits (as a replacement). This highlights the difference between user actions that modify an existing page background and user actions that replace the page background with a completely new one.

[0443] MList field

[0444] The MList field is another higher-order field. It takes an existing field and generates a monotonically growing list of entities from the original field. List entities can evolve by inserting new entities from the original field at any position and by updating any existing entities with increments from the original field.

[0445] In Haskell, an MList field can be represented as follows:

[0446]

[0447] For example, in the context of a collaborative design application, a page might have a list of design elements. The collection of design elements can be represented by an MList. <element>Description: A field of an element that describes the pattern of a single element.

[0448] However, in practice, MList fields are not used directly. Instead, they are used in the context of list fields (as described below).

[0449] IDict domain

[0450] The IDict domain takes domain A and its state s and generates a new domain (IDictAs). Each state of the domain is a dictionary of string keywords for state A, and all other keywords are mapped to S.

[0451] For example, given a counter field, the (IDict counter 0) field:

[0452] - It has a dictionary representing the state {"foo": 1, "bar": 2}, where:

[0453] The keyword "foo" is mapped to counter state 1;

[0454] The keyword "bar" is mapped to counter state 2; and

[0455] + All other possible keywords (e.g., "baz", "quux", etc.) are mapped to counter state 0.

[0456] - An increment {"foo": +1, "bar": 2} representing a dictionary increment, where:

[0457] The status bar for the keyword "foo" will increase by +1 (based on the counter increment).

[0458] The status of the keyword "bar" will increase by +2 (based on the counter increment).

[0459] The status of all other keywords (e.g., "baz", "quux", etc.) will increase by +0 (according to the counter identity increment of +0).

[0460] The IDict identity function (identity s) generates an empty dictionary.

[0461] The IDict application function (applysd) produces a new dictionary with keywords from s and d. Each new keyword k is mapped to a state produced by (applys[k]d[k]) from the component domain, filtered to omit entries whose values ​​are equal to the dictionary's default state.

[0462] The IDict unapply function (unapplysd) produces a new dictionary with keywords from s and d. Each new keyword k maps to a state produced by (unapplys[k]d[k]) from the component domain, filtered to omit entries whose values ​​are equal to the dictionary's default state.

[0463] The IDict composition function (composede) generates a new dictionary with keywords from d and e. Each new keyword k is mapped to an increment generated by (composed[k]e[k]) from the component domain, filtered to omit entries whose values ​​are equal to the unit increment from the component domain.

[0464] The IDict transform function (transform sc) generates a new dictionary (c' and s') with keywords from s and c. (c'[k], s'[k]) is set to the increment produced by (transform s[k]c[k]) from the component domain, and filtered to omit entries whose values ​​are equal to the unit increment from the component domain.

[0465] To further illustrate the IDict field, the following is an example from the (IDict counter 0) field:

[0466] identity{}=true

[0467] apply{"foo": 1, "bar": 2} {"foo": +1, "bar": -2, "baz": +1} = {"foo": 2, "baz": 1}

[0468] unapply{"foo": 2, "baz": 1} {"foo": +1, "bar": -2, "baz": +1} = {"foo": 1, "bar": 2}

[0469] compose{"foo": +1, "bar": +2} {"foo": +1, "bar": -2, "baz": +1} = {"foo": +2, "baz": +1}

[0470] transform({"foo": +1, "bar": +2}, {"foo": +1, "baz": +3}) = ({"foo": +1, "baz": +3}, {"foo": +1, "bar": +2})

[0471] Additional domain

[0472] The domain defined above is sufficient to contain the working set of the transformation algorithm.

[0473] However, additional domains can be provided.

[0474] For example, the following additional fields are functionally equivalent to the combination of the above fields, but offer a direct implementation that provides ease of operation and efficiency.

[0475] Option field

[0476] An option field takes a field and modifies it with optionality. Functionally, an option field can be represented using either of the above and a cell field. Specifically, given a field A, the optional field of A is equivalent to none (cell) or A:

[0477] Option a = any unit a

[0478] List field

[0479] The monotonic nature of the MList field (where it only grows) can make it an inconvenient data model in some applications. The list field provides a list from which items can also be deleted.

[0480] Given a domain A, a general list of entities A is defined as a monotonically increasing list of optional empty frames of entities A:

[0481] List a = MList(Box(Option a))

[0482] Understandably, the basic list state is still monotonous, but it can be treated as a regular list by filtering out its empty items:

[0483]

[0484] Remove the element with state 's' from the list that has an update increment:

[0485] Update(Box.Replace(Just s)Nothing)

[0486] This update evolves the list into a list with cells / none at the location of the deleted entity.

[0487] Mingwen Domain

[0488] A plaintext field defines a string of editable text, where characters can be inserted or deleted at any position within the string. Functionally, this is equivalent to a constant list of characters (as described above):

[0489] Plaintext = List (ConstChar)

[0490] Dict domain

[0491] Similar to how a list field is an alternative to an MList field, a Dict field is an alternative to an IDict field, where items are made selectable by wrapping them in a box.

[0492] Dict a = IDict(Box(Option a))

[0493] The "insertion" of an entry with the keyword k and the value s is interpreted as applying op:

[0494] Update k(Box.Replace Nothing(Just s))

[0495] Similarly, "deleting" an entry with the keyword k and the value s is interpreted as applying the op:

[0496] Update k(Box.Replace(Just s)Nothing)

[0497] MStream domain

[0498] The MStream field is similar to the MList field, but with different increments. These increments describe growth by cloning (and modifying) list entries, rather than inserting new list entries with a specific state.

[0499] The MStream domain takes domain A and produces a monotonically increasing stream of entities from A, paired with states from A representing infinite prefixes and infinite suffixes, called "background states". For example, the (MstreamCounter0) domain is a counter stream with a background state of 0. In this domain, the states are:

[0500] [4, 2, 8]

[0501] Corresponding to the finite list [4, 2, 8] embedded in the background of 0s:

[0502]

[0503] The increment of the MStream field is the same as the increment of the MList field, except that (insert s)op is replaced by (copy d)op.

[0504] data MStreamOp sd=Copy d|Update d

[0505] type MStreamState s = [s]

[0506] type MStreamDelta sd=[MStreamOp sd]

[0507] Similar to MList, (Updated)op means updating a list cell with an increment d. (Copyd)op means inserting a new cell as a copy of the previous cell, modified by the increment d.

[0508] AttributeStream field

[0509] Like list and Dict fields, AttributeStream fields are combinations of other fields.

[0510] Specifically, the AttributeStream field represents a specific instance of the MStream field, as a "dictionary of attributes" stream:

[0511] AttributeStream=Stream(IDict(Box(Optional(Const String)))Unit)

[0512] In other words, the state in the AttributeStream field is a dictionary stream (i.e., a list), where each dictionary is a mapping from string keywords to string values. For example:

[0513] [{"font-size": "10", "font-weight": "bold"},

[0514] {"font-size":"10","colour":"red"},

[0515] {"colour": "red"}]

[0516] For ease of description, the above disclosure assumes that any user in a collaborative session can perform any available action on a given object (i.e., read / view, write / edit, create, delete). However, the actions available to a given user and / or a given entity can be modified by permissions. For example, permissions can be created that allow a given user to view but not edit a given object.

[0517] The processes shown in the diagram and described above define operations in a specific order to explain various features. In some cases, the described and / or illustrated operations can be performed in a different order than those shown / described, one or more operations can be combined into a single operation, a single operation can be divided into multiple separate operations, and / or the functionality implemented by one or more described / illustrated operations can be implemented by one or more alternative operations. Furthermore, the functionality / processing of a given flowchart operation may be performed by different systems or applications.

[0518] Unless otherwise stated, the terms "include" and "comprise" (and their variations, such as "including", "includes", "comprising", "comprises", "comprised", etc.) are inclusive and do not exclude other features, components, wholes, steps, or elements.

[0519] Unless the context requires it, the terms "first," "second," etc., are used to distinguish various elements and features, without any sequential meaning. For example, without departing from the scope of examples describing various things, the first message can be referred to as the second message, and similarly, the second message can be...

[0520] It should be understood that the embodiments disclosed and defined in this specification extend to alternative combinations of two or more individual features mentioned or clearly visible in the text or drawings. All these different combinations constitute alternative embodiments of this disclosure.

[0521] This specification describes various embodiments with reference to various specific details, which may vary depending on the implementation. Limitations, elements, properties, features, advantages, or characteristics not expressly stated in the claims should not be considered essential or necessary features. Therefore, the specification and drawings are to be considered illustrative rather than restrictive.< / element> < / string>

Claims

1. A computer-implemented method for editing an electronic object, the electronic object being edited in real time by multiple client applications, the method being executed by a first client application, and the method comprising: Maintain a local version of the electronic object; Maintain a local buffer, the local buffer including one or more local increments, each local increment describing one or more edits made by a user of the first client application to a local version of the electronic object; At the first client application, a first local edit is received by the user of the first client application on a local version of the electronic object; In response to receiving the first local edit: Generate a first local increment describing the first local edit; Generate a first client commit message including the first local increment, and transmit the first client commit message to the server system; as well as Add the first local increment to the local buffer; The system receives multiple server increments, each associated with a remote edit performed on the electronic object. The multiple server increments are combined to generate a single combined server increment; The single composed server increment is transformed for one or more of the local increments in the local buffer to generate a transformed server increment; as well as The local version of the electronic object is edited by applying the transformed server increment to the local version of the electronic object.

2. The computer-implemented method according to claim 1, wherein, Storing the first local increment in the local buffer includes marking the first local increment as unacknowledged.

3. The computer-implemented method according to claim 2 further includes: Receive a first server confirmation message from the server system, wherein the first server confirmation message confirms the first local increment; as well as In response to receiving the first server confirmation message, the first local increment is cleared from the local buffer.

4. The computer-implemented method according to claim 3, wherein: The first client submission message also includes a first client version identifier; The first server confirmation message includes the first client version identifier; The local buffer includes one or more additional local increments, each of which is marked as unacknowledged upon receiving the first server acknowledgment message, and each of the one or more additional local increments is associated with a client version identifier indicating an earlier version than the first client version identifier; and In response to receiving the first server confirmation message, the method further includes clearing one or more of the additional local increments from the client buffer.

5. The computer-implemented method according to claim 1, further comprising: Receive a second local edit made by a user of the first client application to a local version of the electronic object; Generate a second local increment corresponding to the second local edit; Receive a third local edit made by a user of the first client application to a local version of the electronic object; Generate a third local increment corresponding to the third local edit; The second local increment and the third local increment are combined to generate a fourth local increment; as well as Add the fourth local increment to the local buffer.

6. A computer-implemented method for facilitating real-time editing of electronic objects, the method comprising: Maintain an object history data storage device, which includes multiple object history items; Provide a first client synchronizer associated with a first client application, the first client synchronizer being configured as follows: Maintain a first server-side incremental buffer, which is associated with the first client application and includes multiple buffer objects. Receive multiple client increments generated by the first client application, each client increment being related to a local edit made to the electronic object by a user of the first client application; The multiple client increments are combined to generate a first combined client increment; For one or more server-side incremental transformations, the client increment composed of the first transformed layer is generated to produce the client increment of the first transformed layer. The client increment formed by the first step, which involves incremental transformation of one or more server-side components, includes: Transform the first assembled client increment for one or more server-side increments included in a plurality of buffer objects in the first server-side increment buffer; and / or The first client increment is transformed for one or more server-side increments in the object history items stored in the object history data storage; A first object history item is generated and stored in the object history data storage, the first object history item including a first client identifier associated with the first client application and the first transformed client increment.

7. The computer-implemented method according to claim 6, wherein, The first client synchronizer is also configured as follows: Retrieve the first object history item from the object history data storage; The first object's history item is determined to include the first client identifier; and In response to determining that the first object history item includes the first client identifier: Generate a server confirmation message, the server confirmation message including a server version identifier contained in the first object history item and a client version identifier contained in the first object history item; and The server confirmation message is sent to the first client application.

8. The computer-implemented method according to claim 6, wherein, The first client synchronizer is also configured as follows: Retrieve a second object history item from the object history data storage, the second object history item including a second client identifier and a second client increment; It is determined that the second client identifier is not associated with the first client application; as well as In response to determining that the second client identifier is not associated with the first client application, a first buffer object is created and added to the first server-side increment buffer, the first buffer object including the second client increment.

9. The computer-implemented method according to claim 8, wherein, The first client synchronizer is also configured as follows: Generate a server commit message that includes the second client increment; and The server submits the message to the first client application.

10. The computer-implemented method according to claim 6, wherein, The first client synchronizer is also configured as follows: Retrieve a second object history item from the object history data storage, the second object history item including a second client identifier and a second client increment; It is determined that the second client identifier is not associated with the first client application; In response to determining that the second client identifier is not associated with the first client application, a first buffer object is created and added to the first server-side increment buffer, the first buffer object including the second client increment; Retrieve a third object history item from the object history data storage, the third object history item including a third client identifier and a third client increment; It is determined that the third client identifier is not associated with the first client application; In response to determining that the third client identifier is not associated with the first client application, a second buffer object is created and added to the first server-side increment buffer, the second buffer object including the third client increment; The second client increment and the third client increment are combined to generate the combined client increment; Generate a server commit message that includes the composed client increment; as well as The server submits the message to the first client application.

11. A computer processing system, comprising: Processing unit; communication interface; and A non-transitory computer-readable storage medium storing instructions that, when executed by the processing unit, cause the processing unit to: Maintain local versions of electronic objects that are edited in real time by multiple client applications; Maintain a local buffer, the local buffer including one or more local increments, each local increment describing one or more edits made by a user of the computer processing system to a local version of an electronic object; At the computer processing system, a first local edit of the local version of the electronic object is received by a user of the computer processing system. In response to receiving the first local edit: Generate a first local increment describing the first local edit; Generate a first client commit message including the first local increment, and transmit the first client commit message to the server system; as well as Add the first local increment to the local buffer; Multiple server increments are received from the server system via the communication interface, each server increment being related to remote editing of the electronic object; The multiple server increments are combined to generate a single combined server increment; The single composed server increment is transformed for one or more of the local increments in the local buffer to generate a transformed server increment; as well as The local version of the electronic object is edited by applying the transformed server increment to the local version of the electronic object.

12. The computer processing system according to claim 11, wherein, The execution of the instruction also causes the processing unit to: Receive a second local edit of the local version of the electronic object by a user of the computer processing system; Generate a second local increment corresponding to the second local edit; Receive a third local edit of the local version of the electronic object by a user of the computer processing system; Generate a third local increment corresponding to the third local edit; The second local increment and the third local increment are combined to generate a fourth local increment; as well as Add the fourth local increment to the local buffer.

13. A computer processing system, comprising: Processing unit; communication interface; and A non-transitory computer-readable storage medium storing instructions that, when executed by the processing unit, cause the processing unit to: Maintain an object history data storage device, which includes multiple object history items related to the electronic object; Provide a first client synchronizer associated with a first client application, and configure the first client synchronizer as follows: Maintain a first server-side incremental buffer, which is associated with the first client application and includes multiple buffer objects. The communication interface receives multiple client increments generated by the first client application, each client increment being related to a local edit made by a user of the first client application to the electronic object. The multiple client increments are combined to generate a first combined client increment; For one or more server-side incremental transformations, the client increment composed of the first transformed layer is generated to produce the client increment of the first transformed layer. The client increment formed by the first step, which involves incremental transformation of one or more server-side components, includes: Transform the first assembled client increment for one or more server-side increments included in a plurality of buffer objects in the first server-side increment buffer; and / or The first client increment is transformed for one or more server-side increments in the object history items stored in the object history data storage; A first object history item is generated and stored in the object history data storage, the first object history item including a first client identifier associated with the first client application and the first transformed client increment.

14. The computer processing system according to claim 13, wherein, The first client synchronizer is also configured as follows: Retrieve the first object history item from the object history data storage; The first object's history item is determined to include the first client identifier; and In response to determining that the first object history item includes the first client identifier: Generate a server confirmation message, the server confirmation message including a server version identifier contained in the first object history item and a client version identifier contained in the first object history item; and The server confirmation message is sent to the first client application.

15. The computer processing system according to claim 13, wherein, The first client synchronizer is also configured as follows: Retrieve a second object history item from the object history data storage, the second object history item including a second client identifier and a second client increment; It is determined that the second client identifier is not associated with the first client application; as well as In response to determining that the second client identifier is not associated with the first client application, a first buffer object is created and added to the first server-side increment buffer, the first buffer object including the second client increment.

16. The computer processing system according to claim 15, wherein, The first client synchronizer is also configured as follows: Generate a server commit message that includes the second client increment; and The server submits the message to the first client application.

17. The computer processing system according to claim 13, wherein, The first client synchronizer is also configured as follows: Retrieve a second object history item from the object history data storage, the second object history item including a second client identifier and a second client increment; It is determined that the second client identifier is not associated with the first client application; In response to determining that the second client identifier is not associated with the first client application, a first buffer object is created and added to the first server-side increment buffer, the first buffer object including the second client increment; Retrieve a third object history item from the object history data storage, the third object history item including a third client identifier and a third client increment; It is determined that the third client identifier is not associated with the first client application; In response to determining that the third client identifier is not associated with the first client application, a second buffer object is created and added to the first server-side increment buffer, the second buffer object including the third client increment; The second client increment and the third client increment are combined to generate the combined client increment; Generate a server commit message that includes the composed client increment; and The server submits the message to the first client application.

Images