U.S. patent application number 13/741691 was filed with the patent office on 2015-07-09 for resolving mutations in a partially-loaded spreadsheet model.
This patent application is currently assigned to Google Inc.. The applicant listed for this patent is Google Inc.. Invention is credited to Niklaus Haldimann, Amod Karve.
Application Number | 20150193734 13/741691 |
Document ID | / |
Family ID | 53495478 |
Filed Date | 2015-07-09 |
United States Patent
Application |
20150193734 |
Kind Code |
A1 |
Karve; Amod ; et
al. |
July 9, 2015 |
RESOLVING MUTATIONS IN A PARTIALLY-LOADED SPREADSHEET MODEL
Abstract
A method of resolving mutations in a partially-loaded
spreadsheet model includes loading onto a client computer a first
chunk of a spreadsheet stored on a server, where the first chunk
represents a first range of cells in the spreadsheet, and
requesting a second chunk of the spreadsheet from the server, where
the second chunk represents a second range of cells in the
spreadsheet. The method further includes storing a plurality of
pending user mutations on the client computer generated by a user
on the client computer, where the plurality of pending user
mutations are applied to the first chunk, and receiving from the
server a plurality of collaborator mutations and the second chunk.
The method further includes transforming the plurality of pending
user mutations against the plurality of collaborator mutations, and
applying the transformed plurality of pending user mutations to the
second chunk.
Inventors: |
Karve; Amod; (Clifton,
NJ) ; Haldimann; Niklaus; (New York, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Google Inc.; |
|
|
US |
|
|
Assignee: |
Google Inc.
Mountain View
CA
|
Family ID: |
53495478 |
Appl. No.: |
13/741691 |
Filed: |
January 15, 2013 |
Current U.S.
Class: |
709/205 |
Current CPC
Class: |
G06Q 10/10 20130101;
G06F 40/18 20200101 |
International
Class: |
G06Q 10/10 20060101
G06Q010/10 |
Claims
1. A method for resolving mutations in a partially-loaded
spreadsheet model, the method comprising: loading onto a client
computer a first chunk of a spreadsheet stored on a server, wherein
the first chunk represents a first range of cells in the
spreadsheet; requesting a second chunk of the spreadsheet from the
server, wherein the second chunk represents a second range of cells
in the spreadsheet; storing a plurality of pending user mutations
on the client computer generated by a user on the client computer,
wherein the plurality of pending user mutations are applied to the
first chunk; receiving from the server a plurality of collaborator
mutations; receiving from the server the second chunk; transforming
the plurality of pending user mutations against the plurality of
collaborator mutations; and applying the transformed plurality of
pending user mutations to the second chunk.
2. The method of claim 1, wherein the transforming includes
applying an operational transformation on the plurality of pending
user mutations against the plurality of collaborator mutations.
3. The method of claim 1, wherein each collaborator mutation in the
plurality of collaborator mutations is associated with a revision
number and the second chunk is associated with a revision
number.
4. The method of claim 3, the method further comprising applying to
the second chunk each collaborator mutation with a revision number
higher than the revision number of the second chunk.
5. The method of claim 3, wherein the revision numbers of each
collaborator mutation and the second chunk is assigned by the
server.
6. The method of claim 1, the method further comprising:
transforming the plurality of collaborator mutations against the
plurality of pending user mutations; and applying the transformed
plurality of collaborator mutations to the first chunk.
7. The method of claim 1, wherein a first user mutation in the
plurality of pending user mutations affects a cell in the second
range of cells.
8. The method of claim 1, wherein a first collaborator mutation in
the plurality of collaborator mutations affects a cell in the first
range of cells.
9. The method of claim 1, wherein the pending user mutations
include user mutations that have not been sent to the server.
10. The method of claim 1, wherein the pending user mutations
include user mutations that have been sent to the server but
without an acknowledgement from the server that the user mutations
have been saved.
11. A system for resolving mutations in a partially-loaded
spreadsheet model, the system comprising: a client computer,
wherein the client computer is configured to: communicate with a
server using a communication connection; load a first chunk of a
spreadsheet stored on the server, wherein the first chunk
represents a first range of cells in the spreadsheet; request a
second chunk of the spreadsheet from the server, wherein the second
chunk represents a second range of cells in the spreadsheet; store
a plurality of pending user mutations generated by a user on the
client computer, wherein the plurality of pending user mutations
are applied to the first chunk; receive from the server a plurality
of collaborator mutations; receive from the server the second
chunk; transform the plurality of pending user mutations against
the plurality of collaborator mutations; and apply the transformed
plurality of pending user mutations to the second chunk.
12. The system of claim 11, wherein the client computer transforms
the plurality of pending user mutations by applying an operational
transformation on the plurality of pending user mutations against
the plurality of collaborator mutations.
13. The system of claim 11, wherein each collaborator mutation in
the plurality of collaborator mutations is associated with a
revision number and the second chunk is associated with a revision
number.
14. The system of claim 13, wherein the client computer is further
configured to apply to the second chunk each collaborator mutation
with a revision number higher than the revision number of the
second chunk.
15. The system of claim 13, wherein the revision numbers of each
collaborator mutation and the second chunk is assigned by the
server.
16. The system of claim 11, wherein the server is further
configured to: transform the plurality of collaborator mutations
against the plurality of pending user mutations; and apply the
transformed plurality of collaborator mutations to the first
chunk.
17. The system of claim 11, wherein a first user mutation in the
plurality of pending user mutations affects a cell in the second
range of cells.
18. The system of claim 11, wherein a first collaborator mutation
in the plurality of collaborator mutations affects a cell in the
second range of cells.
19. The system of claim 11, wherein the pending user mutations
include user mutations that have not been sent to the server.
20. The system of claim 11, wherein the pending user mutations
include user mutations that have been sent to the server but
without an acknowledgement from the server that the user mutations
have been saved.
21. A method for resolving mutations in a partially-loaded
spreadsheet model, the method comprising: loading onto a client
computer a first chunk of a spreadsheet stored on a server, wherein
the first chunk represents a first range of cells in the
spreadsheet; searching local memory of the client computer for a
second chunk of the spreadsheet, wherein the second chunk
represents a second range of cells in the spreadsheet; storing a
plurality of pending user mutations on the client computer
generated by a user on the client computer, wherein the plurality
of pending user mutations are applied to the first chunk; receiving
from the server a plurality of collaborator mutations; retrieving
the second chunk from the local memory; transforming the plurality
of pending user mutations against the plurality of collaborator
mutations; and applying the transformed plurality of pending user
mutations to the second chunk.
22. The method of claim 21, wherein the local memory is a browser
cache.
23. The method of claim 21, wherein the transforming includes
applying an operational transformation on the plurality of pending
user mutations against the plurality of collaborator mutations.
24. The method of claim 21, wherein each collaborator mutation in
the plurality of collaborator mutations is associated with a
revision number and the second chunk is associated with a revision
number.
25. The method of claim 24, the method further comprising applying
to the second chunk each collaborator mutation with a revision
number higher than the revision number of the second chunk.
26. The method of claim 24, wherein the revision numbers of each
collaborator mutation and the second chunk is assigned by the
server.
27. The method of claim 21, the method further comprising:
transforming the plurality of collaborator mutations against the
plurality of pending user mutations; and applying the transformed
plurality of collaborator mutations to the first chunk.
28. The method of claim 21, wherein a first user mutation in the
plurality of pending user mutations affects a cell in the second
range of cells.
29. The method of claim 21, wherein a first collaborator mutation
in the plurality of collaborator mutations affects a cell in the
first range of cells.
30. The method of claim 21, wherein the pending user mutations
include user mutations that have not been sent to the server.
31. The method of claim 21, wherein the pending user mutations
include user mutations that have been sent to the server but
without an acknowledgement from the server that the user mutations
have been saved.
Description
BACKGROUND
[0001] Cloud computing and cloud storage systems provide users with
the ability to store and edit electronic documents and other files
on a remote network rather than on a local computer. This allows
users the ability to access the remotely stored files from any
device that is capable of connecting with the remote network, for
example using a web browser over an Internet connection. Users
typically log into an account on the cloud computing system using a
username and password. The cloud computing system provides a user
interface for users to view, edit, and manage files stored on the
system. Cloud computing systems also provide users the ability to
share files with other users and to allow collaboration between
users on the same file.
[0002] One type of file that may be stored in a cloud computing
system is a spreadsheet. Spreadsheets are usually arranged as a set
of rows and columns that define cells, where each cell may contain
data, formulae, or other information. Spreadsheets range in size
and larger spreadsheets may contain many rows or columns of
information. Typically, when a file from a cloud computing system
is loaded onto a client computer the data contents of the entire
file are sent from the server to the client computer. For large
spreadsheets, the amount of data may range in the megabytes or
above. Downloading the information to the client computer may take
a long time and may also slow down the rendering process on the
client computer. If a user only wants to edit a certain portion of
the spreadsheet, loading the entire spreadsheet onto the client
computer wastes time and resources.
[0003] In addition, multiple users may have access to the
spreadsheet and may edit the spreadsheet concurrently. While a user
on client computer is editing the spreadsheet, the spreadsheet is
not instantaneously updated with edits submitted by other users.
Rather, the cloud computing system coordinates edits received from
various users. When a cloud computing system sends edits made by
other collaborators to a client computer, the process of
reconciling the collaborator edits with the edits made by the
current user on the client computer is complex and depends upon the
data structure of the spreadsheet.
SUMMARY
[0004] The systems and methods described herein provide a way for
collaborator and user mutations, or edits, to be resolved in a
partially-loaded spreadsheet model on a cloud computing system. A
cloud computing system includes one or more servers for storing
files for a user, including spreadsheets. Each spreadsheet is
represented by a plurality of chunks, where each chunk encompasses
a range of cells in the spreadsheet. The cloud computing system
maintains a set of chunks for the spreadsheet. Each user with write
access to the spreadsheet may load chunks from the cloud storage
system, where they are locally stored. Each client computer can
then dynamically change its locally-stored set of chunks
independent from the cloud storage system and other users. A
mutation log associated with the spreadsheet is also stored on the
cloud computing system. The mutation log records all mutations, or
edits, made to the spreadsheet by a number of users with write
access to the spreadsheet. The cloud computing system receives
mutations from users, records them in the mutation log, and then
broadcasts the mutation to other collaborators. When a user on a
client computer requests the display of a first chunk of a
spreadsheet stored on the cloud computing system, the cloud
computing system applies the mutations stored in the mutation log
to one or more chunks that span the range of cells of the
spreadsheet requested. The cloud computing system sends the first
chunk to the client computer.
[0005] The user may make edits, or mutations, to the first chunk.
These mutations are stored in a pending queue on the client
computer and are sent in batches to the cloud computing system.
User mutations that have not been saved on the cloud computing
system are kept in the pending queue. The client computer may
request a copy of a second chunk from the cloud computing system.
During the time it takes the cloud computing system to receive the
second chunk from the cloud computing system, the user may have
made additional user mutations that are stored in the pending
queue. Mutations made by collaborators are also sent to the client
computer. The pending user mutations in the pending queue are
operationally transformed against the collaborator mutations before
being sent to the cloud computing system. Operational transforms
ensure consistency of results regardless of the order in which the
mutations are applied. In addition, the collaborator mutations are
transformed against the pending user mutations before being applied
to the first chunk on the client computer. When the client computer
receives the second chunk from the cloud computing system, the
transformed pending user mutations are applied to the second chunk.
In addition, the second chunk and the collaborator mutations have
associated revision numbers. Any collaborator mutation with a
revision number higher than the revision number of the second chunk
is applied to the second chunk. When all the mutations have been
applied, the client computer displays the second chunk to the
user.
[0006] One aspect described herein discloses a method of resolving
mutations in a partially-loaded spreadsheet model. The method
includes loading onto a client computer a first chunk of a
spreadsheet stored on a server, where the first chunk represents a
first range of cells in the spreadsheet, and requesting a second
chunk of the spreadsheet from the server, where the second chunk
represents a second range of cells in the spreadsheet. The method
further includes storing a plurality of pending user mutations on
the client computer generated by a user on the client computer,
where the plurality of pending user mutations are applied to the
first chunk, and receiving from the server a plurality of
collaborator mutations and the second chunk. The method further
includes transforming the plurality of pending user mutations
against the plurality of collaborator mutations, and applying the
transformed plurality of pending user mutations to the second
chunk.
[0007] Another aspect described herein discloses a system for
resolving mutations in a partially-loaded spreadsheet model, where
the system includes a client computer. The client computer is
configured to communicate with a server using a communication
connection, load a first chunk of a spreadsheet stored on the
server, where the first chunk represents a first range of cells in
the spreadsheet, and request a second chunk of the spreadsheet from
the server, where the second chunk represents a second range of
cells in the spreadsheet. The client computer is further configured
to store a plurality of pending user mutations generated by a user
on the client computer, where the plurality of pending user
mutations are applied to the first chunk, and receive from the
server a plurality of collaborator mutations and the second chunk.
The client computer is further configured to transform the
plurality of pending user mutations against the plurality of
collaborator mutations, and apply the transformed plurality of
pending user mutations to the second chunk.
[0008] Another aspect described herein discloses a method for
resolving mutations in a partially-loaded spreadsheet model, where
the method includes loading onto a client computer a first chunk of
a spreadsheet stored on a server, where the first chunk represents
a first range of cells in the spreadsheet. The method further
includes searching local memory of the client computer for a second
chunk of the spreadsheet, where the second chunk represents a
second range of cells in the spreadsheet, and storing a plurality
of pending user mutations on the client computer generated by a
user on the client computer, where the plurality of pending user
mutations are applied to the first chunk. The method further
includes receiving from the server a plurality of collaborator
mutations and retrieving the second chunk from the local memory.
The method further includes transforming the plurality of pending
user mutations against the plurality of collaborator mutations, and
applying the transformed plurality of pending user mutations to the
second chunk.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The methods and systems may be better understood from the
following illustrative description with reference to the following
drawings in which:
[0010] FIG. 1 shows a client-server system for resolving mutations
in a partially-loaded spreadsheet model in accordance with an
implementation as described herein;
[0011] FIG. 2 shows the components of a client computer configured
for resolving mutations in a partially-loaded spreadsheet model in
accordance with an implementation as described herein;
[0012] FIG. 3 shows a partially-loaded spreadsheet model in
accordance with an implementation as described herein;
[0013] FIG. 4 shows a mutation log for a partially-loaded
spreadsheet model in accordance with an implementation as described
herein;
[0014] FIG. 5 shows another client-server system for resolving
mutations in a partially-loaded spreadsheet model in accordance
with an implementation as described herein;
[0015] FIG. 6 shows a diagram for transforming pending mutations in
accordance with an implementation as described herein;
[0016] FIG. 7 shows another client-server system for resolving
mutations in a partially-loaded spreadsheet model in accordance
with an implementation as described herein;
[0017] FIG. 8 shows another diagram for transforming pending
mutations in accordance with an implementation as described herein;
and
[0018] FIG. 9 shows a method for resolving mutations in a
partially-loaded spreadsheet model in accordance with an
implementation as described herein.
DETAILED DESCRIPTION
[0019] To provide an overall understanding of the systems and
methods described herein, certain illustrative embodiments will now
be described, including systems and methods for resolving
collaborator and user mutations in a partially-loaded spreadsheet
model on a cloud computing system. However, it will be understood
that the systems and methods described herein may be adapted and
modified as is appropriate for the application being addressed and
that the systems and methods described herein may be employed in
other suitable applications, and that such other additions and
modifications will not depart from the scope thereof. In
particular, a server or system as used in this description may be a
single computing device or multiple computing devices working
collectively and in which the storage of data and the execution of
functions are spread out amongst the various computing devices. One
or more servers may host a cloud computing system, a cloud storage
system, or both operating in tandem.
[0020] Aspects of the systems and methods described herein provide
a cloud computing system capable of delivering a partially-loaded
spreadsheet model using dynamically-sized chunks. A spreadsheet may
be represented by one or more chunks, where each chunk encompasses
a range of cells in the spreadsheet. One or more servers hosting a
cloud computing system maintains a set of chunks for the
spreadsheet. Each user with write access to the spreadsheet may
load chunks from the cloud computing system, where they are locally
stored. Each client computer can then dynamically change its
locally-stored set of chunks independent from the cloud computing
system and other user. All chunks are initially empty. A mutation
log is associated with the spreadsheet and stored on the server.
The mutation log records all mutations made by users to the
spreadsheet to any chunk of the spreadsheet. When a user on a
client computer requests a range of cells of the spreadsheet from
the server, the server applies all the mutations stored in the
mutation log to one or more of its chunks representing the range of
cells of the spreadsheet request and sends the copies of the chunks
to the client computer. Partially-loaded spreadsheet models using
dynamically-sized chunks are further described in co-pending U.S.
patent application number [108827-1126-101], entitled, "DYNAMICALLY
SIZING CHUNKS IN A PARTIALLY LOADED SPREADSHEET MODEL," which is
incorporated by reference herein in its entirety.
[0021] The user may make mutations to the first chunk. These
mutations are stored in a pending queue on the client computer and
are sent in batches to the cloud computing system. User mutations
that have not been saved on the cloud computing system are kept in
the pending queue. The client computer may request a copy of a
second chunk from the cloud computing system. A set of pending user
mutations may also be sent to the cloud computing system along with
the request for the second chunk. While the cloud computing system
generates a copy of the second chunk to send to the client
computer, the user may have made additional user mutations that are
stored in the pending queue. Mutations made by collaborators are
also sent to the client computer. The pending user mutations and
collaborator mutations are reconciled using operational
transformations. The pending user mutations in the pending queue
are transformed against the collaborator mutations before being
sent to the cloud computing system. In addition, the collaborator
mutations are transformed against the pending user mutations before
being applied to the first chunk on the client computer. The
pending user mutations and collaborator mutations may affect more
than one chunk. For example, the addition or deletion of rows or
columns, changes to cell formulae in the first chunk, or changes to
cell values in the first chunk that are referenced in cells in the
second chunk may affect the values of cells in the second chunk.
Thus, when the client computer receives the second chunk from the
cloud computing system the transformed pending user mutations are
applied to the second chunk. In addition, the second chunk and the
collaborator mutations have associated revision numbers. Any
collaborator mutation with a revision number higher than the
revision number of the second chunk is applied to the second chunk.
When all the mutations have been applied, the client computer
displays the second chunk to the user. In this manner, the client
computer resolves user and collaborator mutations when loading and
displaying chunks of a partially-loaded spreadsheet stored on a
cloud computing system.
[0022] A cloud computing system stores files for users and allows
users to view, edit, share, and download those files using client
computers connected to the cloud computing system over a remote
network. One type of file that a cloud computing system may store
is a spreadsheet. FIG. 1 illustrates a client-server system, where
the server supports a cloud computing system for storing
spreadsheets and other files. System 100 includes one or more
servers 102 which collectively provide a cloud computing system for
storing files such as spreadsheet file 104. System 100 also
includes a number of client computers 106a through 106d which
connect to servers 102 through a remote network, such as the
Internet. Each one of client computers 106a through 106d may be a
desktop computer, laptop computer, mobile device, tablet, or any
other computing device capable of connecting with servers 102. The
remote network connection may be a wired or wireless Internet
connection, local area network (LAN), wide area network (WAN),
Wi-Fi network, Ethernet, or any other type of known connection.
[0023] A client computer capable of connecting with a cloud
computing system is now described in more detail. Client computer
200 shown in FIG. 2 includes a central processing unit (CPU) 202,
read only memory (ROM) 204, random access memory (RAM) 206,
input/output interface 208, data store 210, and bus 212. Client
computer 200 may have additional components that are not
illustrated in FIG. 2. Bus 212 allows the various components of
client computer 200 to communicate with each other. Input/output
interface 208 allows client computer 200 to communicate with other
devices, such as one or more servers hosting the cloud computing
system. Data store 210 may store, among other things, code for a
web browser for interacting with a cloud computing system and
displaying and editing files stored on the cloud computing system.
Data store 210 also stores one or more chunks for a spreadsheet
loaded from the cloud computing system, for example in the cache of
the web browser.
[0024] Data store 210 for storing files and programs on client
computer 200 may be implemented using non-transitory
computer-readable media. Examples of suitable non-transitory
computer-readable media include all forms of non-volatile memory,
media and memory devices, including by way of example semiconductor
memory devices, e.g., EPROM, EEPROM, and flash memory devices;
magnetic disks, e.g., internal hard disks or removable disks;
magneto-optical disks; and readable, once-writeable, or
re-writeable CD-ROM and DVD-ROM disks.
[0025] A spreadsheet stored on a cloud computing system may be
represented by one or more chunks. FIG. 3 shows an example
spreadsheet 300 with dynamically-sized chunks. Spreadsheet 300 as
illustrated has rows 1 through 14 and columns A through E, although
a spreadsheet may include any number of rows and columns. The cloud
computing system may represent the entire spreadsheet 300 using one
or more chunks, where each chunk represents a range of cells in the
spreadsheet. In FIG. 3, chunk 302 represents rows 1 through 7 and
chunk 304 represents rows 8 through 14. Chunks may represent any
range of rows, columns, or a combination of rows and column ranges.
For example, a chunk may represent the first 1,000 rows of a
spreadsheet, the second 1,000 rows of a spreadsheet, the first
1,000 columns of the spreadsheet, or a range of cells covered by
rows 1 through 1,000 and columns 100 through 200. For a small
spreadsheet with 100 rows and 5 columns, the server may only create
one chunk. For a large spreadsheet with 10,000 rows and 20 columns,
the server may create 10 chunks, each spanning 1,000 rows. A
spreadsheet file may include a number of individual sheets, each
having its own tab, arranged in a "workbook" structure. Chunks may
be created for each sheet within the spreadsheet file.
[0026] The server maintains a master set of chunks for a
spreadsheet. Each user with write access to the spreadsheet may
load chunks from the cloud storage system, where they are locally
stored. Each client computer can then dynamically change its
locally-stored set of chunks independent from the cloud storage
system and other users. The server may initially set the chunks for
each user to be identical, but the size and range of the chunks are
further customized by the client computer and may be based on the
capabilities of the client computer. For example, if the client
computer is a desktop computer with a large cache, the chunk sizes
may be large. If the client computer is a tablet or mobile device
with smaller memory capabilities, the chunk sizes may be small. The
chunk sizes may also be based on the bandwidth of the connection
between the client computer and the server. The size and range of
the chunks are not static, but may be dynamically changed by the
client computer and server as edits are made to the spreadsheet.
For example, if a user adds many rows to a portion of a spreadsheet
covered by one chunk, the client computer may split the chunk into
two chunks. If a user deletes many rows from a portion of a
spreadsheet covered by one chunk, the client computer may merge the
reduced chunk with another chunk. If a user adds one or deletes one
row in a chunk, the client computer may adjust the boundaries of
adjacent chunks. There may be a tolerance range so that repeated
insertion and deletion of cells does not repeatedly invoke the
merge and split functions, or the boundary adjustment of chunks.
Each chunk has associated ID to uniquely identify it. One of the
chunks in the spreadsheet is designated to store metadata
information about the entire spreadsheet, such as total number of
rows and columns, name of the spreadsheet, chunk IDs, and any other
commonly used metadata fields. This chunk may be the first chunk
that is normally loaded when a user requests the spreadsheet (e.g.
the chunk encompassing row 1 and column 1).
[0027] In addition to representing a spreadsheet by one or more
dynamically-sized chunks, a mutation log is associated with the
spreadsheet. FIG. 4 shows an example of a mutation log 400. The
mutation log applies to all chunks of a spreadsheet, so only one
log is stored per spreadsheet. Alternatively, each chunk of the
spreadsheet may have an associated mutation log. Mutation log 400
stores mutations, or edits, that all users with write access to the
spreadsheet send to the cloud computing system, in the order in
which they are received. The cloud computing system stores the
mutations and also propagates the mutations to each collaborator
that is also working on the same spreadsheet. These edits may be to
set the value of cells, delete cell values, enter formulae into
cells, cut, copy or paste values, add or delete rows and columns,
sorting row or column values, filtering row or column values,
linking to external data, performing a calculation, or any other
operation permissible in an electronic spreadsheet. For example,
mutation log 400 stores a number of set value commands, such as
"Set A2=2" for mutation A, "Set A3=4" for mutation B, and "Set
B3=A2+A3" for mutation C. Mutation log 400 may also store row
addition and deletion mutations, such as "Delete Row 6" for
mutation I and "Add Row 11" for mutation J. Other mutations not
shown in FIG. 4 may also be stored in mutation log 400. In case of
conflicting mutations or mutations that occur at the same time, the
server may engage various conflict resolution mechanisms to
determine the proper order of mutations. The mutations correlate
directly to cells, rows or columns, without regard to chunks. This
allows the size and range of chunks to change without affecting
mutation log 400. The cloud computing system may assign a revision
number to each mutation received. The syntax of the mutations is
not limited to that shown in FIG. 4 but may encompass any known
spreadsheet syntax.
[0028] FIG. 4 also shows two snapshots, one taken after mutation E
and one taken after mutation J. Snapshots are copies of a chunk
generated at a certain time with all the mutations occurring before
that time incorporated into the chunk. For example, snapshot S1 of
a chunk incorporates mutations A-E while snapshot S2 of a chunk
incorporates mutations A-J. Snapshots are created by the cloud
computing system to lessen the time it takes to load a chunk to a
user. For example, when a user requests a chunk from a cloud
computing system after mutation G has been entered, the cloud
computing system takes an empty initial copy of the chunk and
applies mutations A-G stored in mutation log 400 to the empty chunk
to obtain the current state of the chunk, and then sends the chunk
to the client computer. If the cloud computing system has created
and stored snapshot S1, then it only needs to apply mutations F and
G to snapshot S1 of the chunk before sending the copy to the client
computer.
[0029] When a spreadsheet is first generated in a cloud computing
system, one or more chunks are created that represent the cloud
computing system. Initially, all the cells in every chunk have no
value (i.e. the spreadsheet is empty), such as shown in FIG. 3. As
the cloud computing system receives mutations for the spreadsheet
from any number of users, the mutations are stored in a mutation
log associated with the spreadsheet, such as shown in FIG. 4. The
cloud computing system also sends each mutation to the other
collaborators who are working on the same spreadsheet, either
individually or in batches. When a client computer requests an
updated version of a chunk, the cloud computing system applies all
the mutations received up to that point and applies it to an empty
version of the chunk (or a snapshot if one has been created). After
all the mutations have been applied, a copy of the chunk is sent to
the client computer. For example, mutation log 400 depicted in FIG.
4 is associated with empty spreadsheet 300 in FIG. 3. One or more
users send mutations A-E shown in FIG. 4 to the cloud computing
system. The cloud computing system stores these mutations in
mutation log 400. Then a user on a client computer requests a copy
of chunk 302 or chunk 304 of spreadsheet 300. Alternatively, the
cloud computing system may save a snapshot of both chunks after
mutation E has occurred, such as snapshot S1 illustrated in FIG.
4.
[0030] After a client computer has received a chunk from the cloud
computing system, a user on the client computer may make edits to
the locally-stored chunk. These mutations change the copy of the
chunk on the client computer but are not instantaneously
transmitted to the cloud computing system. Rather, the user
mutations are stored in a pending mutation queue. For example, FIG.
5 illustrates a client-server system 500 for providing a cloud
computing and computing service for a client computer. Client
computer 508 connects with one or more servers 502 providing a
cloud computing and cloud storage service. Server 502 stores
spreadsheets, such as spreadsheet 504, that may be partially loaded
onto client computer 508 using dynamically-sized chunks. Client
computer 508 requests a first chunk of spreadsheet 504 from server
502. The server sends client computer 508 a copy of the first chunk
so that client computer 508 has a local copy of the spreadsheet,
shown as spreadsheet 510, which includes the first chunk sent by
server 502. A user on client computer 508 is free to edit the chunk
received from server 502.
[0031] Client computer 508 stores user mutations in a pending queue
512, such as user mutations U1-U5. One or more user mutations
stored in pending queue 512 are sent to server 502 as a save
request. For example, user mutations U1-U3 are sent as a batch to
server 502 as part of a periodic save request. User mutations U1-U3
are placed in sent pending queue 514, a subset of pending queue 512
for mutations that have been sent to the server but have not been
acknowledged as saved by server 502. The server stores user
mutations U1-U3 as well as mutations received from collaborators in
the mutation log associated with the spreadsheet, such as mutation
log 400 in FIG. 4. Server 502 sends client computer 508 a
confirmation that use mutations U1-U3 have been saved. Once client
computer 508 receives the confirmation, user mutations U1-U3 may be
moved out of pending queue 512. User mutations that have not been
sent to the server yet, such as mutations U4 and U5, are stored in
a portion of pending queue 512 termed the unsent pending queue
516.
[0032] Server 502 also sends collaborator mutations 506 to client
computer 508, where the collaborator mutations are stored in a
queue. Collaborator mutations 508 should also be applied to the
first chunk of local spreadsheet 510, but are first reconciled with
all pending user mutations, whether sent to the server or not,
because both the user and collaborator mutations may affect one or
more of the same cells. For example, user mutation U4 deletes row 5
of a spreadsheet, and a later-in-time collaborator mutation M1 sets
cell A6 to the value "5". User mutation U4 shifts the location of
the value of cell A6 and so collaborator mutation M1 is altered so
that it sets the value of cell A5 rather than A6. Otherwise, if M1
is not changed and simply applied to the first chunk it will
produce an incorrect state of the first chunk. Mutations may be
reconciled using operational transformations or other known methods
of consistency and concurrency control in collaborative document
editing. Using operational transformations, collaborator mutation
M1 is transformed against user mutation U4 to produce M1', where
M1' is adjusted to reflect any changes imposed by U4.
[0033] An example of a transformation of user and collaborator
mutations for a spreadsheet stored on a cloud computing system is
shown in FIG. 6. A client computer has a local copy of a
spreadsheet stored on a server, which includes a first chunk. A
user enters user mutations U1 through U5 to the client computer,
where they are stored in a pending queue on the client computer,
such as pending queue 512 in FIG. 5. User mutations U1-U3 are sent
from the client computer to the server, and the client computer has
received a confirmation from the server that the mutations have
been saved. Thus user mutations U1-U3 are removed from the pending
queue. User mutation U4 has been sent to the server but no
confirmation has been received. Thus user mutation U4 is stored in
the sent pending queue. User mutation U5 has not been sent to the
server yet, so it is stored in the unsent pending queue.
Collaborator mutations M1 and M2 are received at the client
computer from the server and should be applied to the first chunk
on the client computer. However, they are first transformed against
all the user mutations in the pending queue, namely U4 and U5. The
order in time the mutations occur is U4, M1, U5, and then M2,
illustrated at 602. When an operational transformation 604 is
applied to the mutations, M1 is transformed against U4 to produce
M1' while M2 is transformed against both U4 and U5 to produce M2''.
After M1 and M2 have been transformed to M1' and M2'' respectively
as shown at 606, they are applied to the first chunk of the
spreadsheet. User mutations U4 and U5 in the pending queue are also
transformed against collaborator mutations M1 and M2 before the
user mutations are sent to the server. This ensures consistency
between the user and collaborator mutations on both the server and
client computer. Thus U4 is transformed against M1 and M2 to
produce U4'' while U5 is transformed against M2 to produce U5'.
Transformed user mutations U4'' and U5', shown at 608, may then be
sent to the server for recordation in the mutation log. In this
manner, the first chunk of the local spreadsheet on the client
computer may be maintained in the correct, up-to-date state as user
mutations and collaborator mutations are received at the client
computer. In addition, correct, up-to-date user mutations may be
sent to the server.
[0034] When a client computer sends a save request to the server,
it may also send a chunk load request for an additional chunk of
the spreadsheet. For example, a client computer may already have a
first chunk of the spreadsheet loaded. The user makes several
mutations to the chunk, which may affect values in a second chunk.
For example, the user may insert or delete rows and columns, make
changes to cell formulae or other dependencies in the first chunk,
or make changes to cell values in the first chunk that are
referenced in cells in the second chunk, all of which may affect
the value of cells in the second chunk. The client computer sends
these mutations to the server and also requests the second chunk.
The channel by which the server sends collaborator mutations to the
client computer is separate from the channel by which the server
delivers chunks. Thus it may be that before the server can process
the request and return a copy of the second chunk, the client
computer may have received additional collaborator mutations from
the server that have not been incorporated by the server into the
second chunk. In addition, the user may have made additional
mutations to the local spreadsheet while waiting for the second
chunk. When the client computer receives the second chunk from the
server, it has to update the second chunk with any user and
collaborator mutations received during the interim.
[0035] System 700 of FIG. 7 shows a client-server system for
delivering cloud computing and cloud storage services to a client
computer. Client computer 708 connects with one or more servers 702
providing a cloud computing and cloud storage service. Server 702
stores spreadsheets, such as spreadsheet 704, that may be partially
loaded onto client computer 708 using dynamically-sized chunks.
Client computer 708 requests a first chunk of spreadsheet 704 from
server 702. The server sends client computer 708 a copy of the
first chunk so that client computer 708 has a local copy of the
spreadsheet, shown as spreadsheet 710, which includes the first
chunk sent by server 702. A user on client computer 708 is free to
edit the chunk received from server 702. User mutations are stored
in pending queue 712. User mutations U1-U3 are sent to server 702
as a save request and are stored in sent pending queue 714 of
pending queue 712. Once server 702 sends client computer 708 a save
confirmation, user mutations U1-U3 are removed from pending queue
714. Client computer 708 may also request a copy of a second chunk
along with the save request. Server 702 generates a copy of the
second chunk by applying the mutations in the mutation log
(including mutations U1-U3) to an empty copy of the second chunk or
a recent snapshot of the second chunk, if one is available. Server
702 then sends the second chunk to the client computer. If client
computer 708 is not connected to the network when the chunk request
is made (e.g. it is offline), then client computer 708 may retrieve
the second chunk from local memory. For example, the second chunk
may be stored in the cache of the web browser and is retrieved from
local storage and displayed on client computer 708. During the time
that server 702 is generating the second chunk (or during the time
client computer 708 is retrieving the second chunk from local
memory), client computer 708 receives two collaborator mutations
706 from server 702. The user on client computer also enters two
additional user mutations U4 and U5 which are stored in unsent
pending queue 716.
[0036] When client computer 708 receives the copy of the second
chunk, the client computer incorporates the additional user and
collaborator mutations. First, client computer 708 checks if the
second chunk incorporates collaborator mutations 706. Server 706
assigns sequential revision numbers to each mutation. For example,
M1 may be assigned revision number 6 and M2 may be assigned
revision number 7. The second chunk also has an associated revision
number. If the revision number of the second chunk is higher than
the revision number of both collaborator mutations 706, then the
second chunk incorporates both mutations. In this case, only the
pending user mutations are applied to the copy of the second chunk.
Thus user mutations U4 and U5 are transformed against collaborator
mutations 706 before being applied to the second chunk. If the
revision number of any collaborator mutation 706 is higher than the
revision number of the second chunk, those collaborator mutations
have not yet been applied to the second chunk. For example, if the
second chunk is at revision number 10 and collaborator mutations M1
and M2 have been assigned revision numbers 11 and 12, the client
computer first applies collaborator mutations M1 and M2 to the
second chunk. Client computer 708 then transforms pending user
mutations U4 and U5 against collaborator mutations 706 and applies
the transformed user mutations to the second chunk.
[0037] An example of updating chunks received at a client computer
is illustrated in FIG. 8. Flow 802 illustrates the order of events.
In a client-server system such as illustrated in FIG. 7, a user is
making edits to a local copy of a first chunk of a spreadsheet
stored on a server. The client computer requests a copy of a second
chunk, which may be in conjunction with a save request of user
mutations of the first chunk. Alternatively, if the client computer
is offline, a copy of the second chunk may be loaded from local
memory. While the server is generating a copy of the second chunk
to send to the client computer or while the client computer is
loading the second chunk from local memory, the server receives
collaborator mutations M1 with revision number 11 and M2 with
revision number 12. The user also makes two additional mutations U4
and U5 that are stored in the pending queue. Mutation U4 was
entered at a time between collaborator mutations M1 and M2, and U5
was entered after M2. After the user enters mutation U5, the client
computer receives a copy of the second chunk at revision 10. Since
the revision number of the second chunk is lower than both
collaborator mutations M1 and M2, the second chunk is updated to
incorporate those mutations. The second chunk is also updated with
the pending user mutations U4 and U5, which are first transformed
against the collaborator mutations. U4 is transformed once against
M2 while U5 does not have to be transformed because it came last in
time. Flow 804 shows the mutations that are applied to the chunk,
including M1, M2, U4', and U5. If the second chunk had revision
number 13, then collaborator mutations M1 and M2 have already been
incorporated into the second chunk and do not need to be applied
again by the client computer. Only the pending user mutations,
transformed against collaborator mutations M1 and M2, are applied
to the second chunk. In this manner, a client computer correctly
updates a newly-loaded chunk that is received from a server (or
from local memory) when additional user and collaborator mutations
are received by the client computer between the time the chunk is
requested and when it actually arrives. As previously described in
relation to FIGS. 5 and 6, chunks currently loaded on the client
computer are also updated. Thus all chunks of the spreadsheet,
whether already loaded or newly received, are kept up-to-date by
the client computer using the systems and methods described
above.
[0038] Methods for maintaining up-to-date chunks and resolving
mutations in a partially-loaded spreadsheet model on a client
computer are now described. One method of resolving mutations in a
partially-loaded spreadsheet model is illustrated in FIG. 9. Method
900 includes loading onto a client computer a first chunk of a
spreadsheet stored on a server, where the first chunk represents a
first range of cells in the spreadsheet, and requesting a second
chunk of the spreadsheet from the server, where the second chunk
represents a second range of cells in the spreadsheet. The method
further includes storing a plurality of pending user mutations on
the client computer generated by a user on the client computer, and
receiving from the server a plurality of collaborator mutations and
the second chunk. The method further includes transforming the
plurality of pending user mutations against the plurality of
collaborator mutations, and applying the transformed plurality of
pending user mutations to the second chunk. Method 900 may be
performed on a client-server system such as illustrated in FIGS. 5
and 7, where the server provides cloud computing and cloud storage
services.
[0039] Method 900 begins when a client computer loads a first chunk
of a spreadsheet stored on a server, illustrated at 902. The
spreadsheet is stored on the server as a partially-loaded model
where the spreadsheet is broken into one or more chunks, each chunk
representing a range of cells in the spreadsheet. The chunks are
downloaded to the client computer when a user on the client
computer views or edits cells within the range of the chunk.
Multiple users may be accessing the spreadsheet simultaneously, and
each client computer maintains a separate set of chunks for the
same spreadsheet. The server receives mutations sent from each user
and incorporates the mutations into a mutation log, such as
illustrated in FIG. 4. Each mutation may be assigned a revision
number. When a client computer requests a first chunk, the server
generates a current version of the first chunk by applying all the
mutations in the mutation log to an empty copy of the first chunk
before sending the copy to the client computer. Alternatively, if a
recent snapshot of the first chunk exists, the server may apply all
mutations occurring in time after the snapshot and then send the
modified copy of the snapshot to the client computer. For example,
the snapshot is associated with a revision number and any mutations
in the mutation log with a higher revision number are applied to
the snapshot.
[0040] When the client computer receives the first chunk from the
server, the user is free to view and edit the first chunk.
Mutations entered by the user are stored in a pending queue, such
as pending queue 712 in FIG. 7. Periodically, the client computer
sends batches of user mutations to the server. The server saves the
user mutations into the mutation log and sends the client computer
an acknowledgement of the save. When the client computer receives
the acknowledgement, the user mutations are moved out of the
pending queue. At a later time, the client computer requests a
second chunk from the server, illustrated at 904. This may happen,
for example, if the user scrolls to a portion of the spreadsheet
that is represented by the second chunk. The request for a second
chunk may also coincide with a save request of pending user
mutations. If the client computer is offline, the client computer
may search local memory (e.g. browser cache) for a copy of the
second chunk.
[0041] Between the time the request for a second chunk is sent and
when the server sends the client computer the second chunk (or when
the client computer locates a copy of the second chunk in local
memory), the user may have made additional user mutations to the
first chunk, illustrated at 906. The user mutations are stored in
the pending queue. The pending queue may also store user mutations
that have been sent to the server but for which no save
acknowledgement has been received. The client computer also
receives from the server collaborator mutations made by other users
who are simultaneously editing the spreadsheet, illustrated at 908.
The server sends collaborator mutations to the client computer
independently of chunk load requests. Each collaborator mutation
has an associated revision number assigned to it by the server,
generally ordered chronologically. The collaborator mutations are
applied to the first chunk on the client computer, but are first
transformed against all pending user mutations in the pending queue
using operational transformations. Transforming the collaborator
mutations ensures that any potential conflicts between the
collaborator mutations and the pending user mutations are resolved,
for example if multiple mutations affect the same cell. Once the
collaborator mutations are transformed, they are applied to the
first chunk. In addition, the pending user mutations are
transformed against the collaborator mutations before being sent to
the server.
[0042] At a later time, the client computer receives the second
chunk from the server, illustrated at 910. The server generates the
second chunk by applying all the mutations in the mutation log to
an empty copy of the second chunk before sending the copy to the
client computer. Alternatively, if a recent snapshot of the second
chunk exists, the server may apply all mutations occurring in time
after the snapshot and then send the modified copy of the snapshot
to the client computer. The mutation log does not include the
pending user mutations stored in the pending queue on the client
computer, and so the pending user mutations have not been
incorporated into the second chunk received by the client computer.
Alternatively, the client computer may load the second chunk from
local memory. The second chunk is associated with a revision
number.
[0043] When the client computer receives the second chunk, the
client computer incorporates the pending user mutations stored in
the pending queue into the second chunk. However, the client
computer first transforms the pending user mutations against the
collaborator mutations, illustrated at 912. Transforming the
pending user mutations ensures that any potential conflicts between
the collaborator mutations and the pending user mutations are
resolved, for example if multiple mutations affect the same cell.
After the pending user mutations are transformed, they are applied
to the second chunk, illustrated at 914. In addition, any
collaborator mutations with a higher revision number than the
second chunk (i.e. collaborator mutations that have not already
been incorporated into the second chunk by the server) are also
applied to the second chunk. If no collaborator mutations have a
higher revision number than the second chunk, no collaborator
mutations need to be applied. After all the mutations are applied
to the second chunk, the client computer may display the correct
up-to-date second chunk to the user. In this manner, the client
computer resolves user and collaborator mutations when loading and
displaying chunks of a partially-loaded spreadsheet stored on a
cloud computing and cloud storage system.
[0044] It will be apparent that aspects of the systems and methods
described herein may be implemented in many different forms of
software, firmware, and hardware in the implementations illustrated
in the figures. The actual software code or specialized control
hardware used to implement aspects consistent with the principles
of the systems and method described herein is not limiting. Thus,
the operation and behavior of the aspects of the systems and
methods were described without reference to the specific software
code--it being understood that one of ordinary skill in the art
would be able to design software and control hardware to implement
the aspects based on the description herein.
[0045] Similarly, while operations are depicted in the drawings in
a particular order, this should not be understood as requiring that
such operations be performed in the particular order shown or in
sequential order, or that all illustrated operations be performed,
to achieve desirable results. In certain circumstances,
multitasking and parallel processing may be advantageous.
* * * * *