A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Computing networks may contain multiple file stores which are accessed by multiple clients. In a shared computing environment, the multiple clients may share access to the same set of files (e.g., files associated with a meeting or conference) on a single destination data store. The multiple clients may further access and store multiple versions of the same set of files on different auxiliary data stores for editing before saving the edited files to the destination data store. Thus, a single file may be edited by multiple clients at the same time on different auxiliary data stores before being saved to the destination data store. As a result, it is often difficult to determine which of a number of versions of the same file on the destination data store is the latest version. Moreover, after being accessed or edited by one or more multiple clients, files may also need to undergo additional processing for conversion into a standardized format for use on the destination data store. This additional processing however, in addition to being time consuming, consumes computing resources of the multiple clients. It is with respect to these considerations and others that the various embodiments of the present invention have been made.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter.
Embodiments are provided for coordinating content from multiple data sources. A native file may be received at a first client computer from an auxiliary data store. The native file may include metadata such as a document title. The first client computer may then send a reserve title request to a primary data store. The reservation request may include the document title of the native file. The first client computer may then receive a response granting the reserve title request from the primary data store. The response may indicate that the native file is locked from further editing by another client computer. The first client computer may then convert the native file from a proprietary file format to a global file format (i.e., a globally viewable document and send the converted native file to the primary data store.
These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are illustrative only and are not restrictive of the invention as claimed.
Embodiments are provided for coordinating content from multiple data sources. A native file may be received at a first client computer from an auxiliary data store. The native file may include metadata such as a document title. The first client computer may then send a reserve title request to a primary data store. The reservation request may include the document title of the native file. The first client computer may then receive a response granting the reserve title request from the primary data store. The response may indicate that the native file is locked from further editing by another client computer. The first client computer may then convert the native file from a proprietary file format to a global file format and send the converted native file to the primary data store.
In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These embodiments may be combined, other embodiments may be utilized, and structural changes may be made without departing from the spirit or scope of the present invention. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.
Referring now to the drawings, in which like numerals represent like elements through the several figures, various aspects of the present invention will be described.
The auxiliary data store 74 may comprise a server computer for storing files and associated metadata. In accordance with an embodiment, the auxiliary data store includes a native file 30 and a server application 76. The native file 30 may include metadata 31. In accordance with an embodiment, the native file 30 may comprise a version of a document (e.g., a word processing document) created and/or updated on the client computer 2 and saved to the auxiliary data store 74 in a proprietary file format. The metadata 31 may include additional information about the native file 30 including, but not limited to, a document title, an external identifier, and a last modification time (i.e., the last time the native file 30 was modified). The metadata 31 will be discussed in greater detail below with respect to
The client computer 2 may include the native file 30, a converted native file 32, client applications 34, and a cookie 52. As discussed above, the native file 30 may comprise a version of a document (e.g., a word processing document) created and/or updated on the client computer 2 in a proprietary file format. The native file 30 may include the metadata 31. The converted native file 32 represents the conversion of the native file 30 from a proprietary file format into a global file format (i.e., a globally viewable document) by the client applications 34. The converted native file 32 may also include the metadata 31 from the native file 30. As will be discussed in greater detail below, the client applications 34 may be configured to convert native files into globally viewable documents so that they may be saved to the primary data store 70 for access and viewing by other client computers. In accordance with an embodiment, the client applications 34 may comprise the OFFICE COMMUNICATOR messaging application and the OFFICE suite of desktop application programs from MICROSOFT CORPORATION of Redmond, Wash. The cookie 52 may comprise a unique identifier associated with the client computer 2 which is used to identify transactions between the client computer 2 and the primary data store 70. Illustrative transactions between the client computer 2 and the primary data store 70 will be described in greater detail below in the discussion of
The primary data store 70 may include the converted native file 32 (with the metadata 31) received from the client computer 2, a converted native file 42 (with metadata 31A) received from the client computer 6, a server application 72, response codes 50, a cookie 52, a content identification 54, and an owning user identification 56. In accordance with various embodiments, the primary data store 70 may comprise a server computer that supports a protocol where messages and files can be exchanged between the server and any connected clients. In accordance with an embodiment, the server application 72 on the primary data store 70 may support the aforementioned protocol. In particular, the server application 72 may comprise the OFFICE COMMUNICATIONS SERVER from MICROSOFT CORPORATION of Redmond, Wash. Illustrative operations performed by the server application 72 in connection with coordinating content from multiple data sources, will be described in greater detail below in the discussion of
The client computer 6 may include the native file 30, a converted native file 42, client applications 34, and the cookie 52A. In accordance with an embodiment, the native file 30 on the client computer 6 may comprise a cached and identical version of the native file 30 stored on the client computer 2. In particular, the native file 30 on the client computer 6 may be a document (e.g., a word processing document) created and/or updated on the client computer 2 in a proprietary file format. The native file 30 may include the metadata 31. The converted native file 42 may comprise an updated (i.e., edited) version of the native file 30 which has been converted from a proprietary file format into a global file format (i.e., a globally viewable document) by the client applications 34. The converted native file 42 may also the metadata 31A. As will be discussed in greater detail below, the client applications 34 may be configured to convert native files into globally viewable documents so that they may be saved to the primary data store 70 for access and viewing by other client computers. In accordance with an embodiment, the client applications 34 may comprise the OFFICE COMMUNICATOR messaging application and the OFFICE suite of desktop application programs from MICROSOFT CORPORATION of Redmond, Wash. The cookie 52A may comprise a unique identifier associated with the client computer 6 which is used to identify transactions between the client computer 6 and the primary data store 70. Illustrative transactions between the client computer 6 and the primary data store 70 will be described in greater detail below in the discussion of
Referring now to
Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the various embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The various embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
The client computer 2 further includes a mass storage device 14 for storing an operating system 38, the native file 30 (including the metadata 31), the converted native file 32 (including the metadata 31), the client applications 34, and the cookie 52. In accordance with various embodiments, the operating system 38 may be suitable for controlling the operation of a networked personal computer, such as the WINDOWS operating systems from MICROSOFT CORPORATION of Redmond, Wash. The mass storage device 14 is connected to the CPU 8 through a mass storage controller (not shown) connected to the bus 10. The mass storage device 14 and its associated computer-readable media provide non-volatile storage for the client computer 2. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by the client computer 2. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media.
Computer storage media includes volatile and non-volatile, removable and non-removable hardware storage media implemented in any physical method or technology for the storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, which can be used to store the desired information and which can be accessed by the client computer 2. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as a computer program product.
According to various embodiments, the client computer 2 may operate in a networked environment using logical connections to remote computers through the network 4 which may comprise, for example, a local network or a wide area network (e.g., the Internet). The client computer 2 may connect to the network 4 through a network interface unit 16 connected to the bus 10. It should be appreciated that the network interface unit 16 may also be utilized to connect to other types of networks and remote computing systems. The client computer 2 may also include an input/output controller 22 for receiving and processing input from a number of input types, including a keyboard, mouse, pen, stylus, finger, and/or other means. Similarly, an input/output controller 22 may provide output to a display device 82, a printer, or other type of output device. Additionally, a touch screen can serve as an input and an output mechanism. It should be appreciated that the client computer 6, the auxiliary data store 74, and the primary data store 70 shown in
The routine 300 begins at operation 305, where the client applications 34 executing on the client computer 2 receives the native file 30 (containing the metadata 31) from the auxiliary data store 74. In particular, the client computer 2 may receive a document file from the auxiliary data store 74 with metadata identifying the document title. In accordance with another embodiment, the metadata 31 may include other data in addition to a document title. For example,
Returning now to
From operation 310, the routine 300 continues to operation 315 where the client applications 34 executing on the client computer 2 receive a response message (i.e., one of the response codes 50) from the primary data store 70 indicating that the Reserve Title request has been granted and that the native file 30 will be locked from further editing by other client computers (e.g., the client computer 6). In particular, upon granting the Reserve Title request from the client computer 2, the primary data store 70 may canonicalize the document title 90 to prevent other users (e.g., malicious users) from generating similar titles and have previously determined that the document title 90 (and/or the external identification 92) has not already been reserved by another user. For example, the response message from the primary data store 70 may indicate that the native file 30 (as identified by at least the document title 90) may be reserved for creation (i.e., the creation of a document to be saved as the converted native file 32) or reserved for upgrade (i.e., the updating of a document already saved as the converted native file 22).
From operation 315, the routine 300 continues to operation 320, where the client applications 34 executing on the client computer 2 converts the native file 30 having a proprietary file format to the converted native file 32 having a global file format (i.e., a globally viewable document).
From operation 320, the routine 300 continues to operation 325, where the client applications 34 executing on the client computer 6 send a Reserve Title request to the primary data store 70. It should be appreciated, that in accordance with an embodiment, the client computer 6 may perform the same determination as discussed above with respect to operation 310, prior to sending the Reserve Title request.
From operation 325, the routine 300 continues to operation 330, where the client computer 6 receives a response message from the primary data store 70 denying the Reserve Title request due to the previously granted request given to the client computer 2 with respect to the native file 30. In particular, the primary data store 70 may send a failure code contained in the response codes 50 because the Reserve Title request granted to the client computer 2 locks out the client computer 6 until the lock is released by the primary data store 70. In accordance with various embodiments, a lock may be released when: (1) a client computer disconnects from the primary data store; (2) a client computer completes uploading a requested file to the primary data store; (3) a state change prevents the client computer from uploading a file (e.g., the client computer loses a network connection to the primary data store); or (4) a client computer sends a “Release Title” message to the primary data store 70. As discussed above at operations 315 and 320, the client computer 2 has already been granted a Reserve Title request for the native file 30 and has converted the native file 30 to a globally viewable format but has not yet uploaded the converted native file 32 to the primary data store 70. Thus, the lock is still active and the client computer 6 will be denied from uploading by the primary data store 70 until the lock has been released.
From operation 330, the routine 300 continues to operation 335, where the client applications 34 executing on the client computer 2 send the converted native file 32 to the primary data store 70. In particular, the client computer 2 may create the converted native file 32 on the primary data store 70 (e.g., if the primary data store 70 does not currently have a file with the same document title or the same document title and the same external identification as the converted native file 32) or update a file already stored on the primary data store 70 with the converted native file 32 (e.g., if the primary data store 70 currently has a file with the same document title or the same document title and the same external identification as the converted native file 32).
From operation 335, the routine 300 continues to operation 340, where the client applications 34 executing on the client computer 6 receive a message from the primary data store 70 indicating that the native file 30 stored on the client computer 6 is available for editing, conversion, and uploading. In particular, after the converted native file 32 has been uploaded from the client computer 2 to the primary data store 70, the lock is released thereby enabling other client computers to upload to the primary data store 70.
From operation 340, the routine 300 continues to operation 345, where the client applications 34 executing on the client computer 6 receive edits to the native file 30 to create an updated version of the file.
From operation 345, the routine 300 continues to operation 350 where the client applications 34 executing on the client computer 6 send a message comprising a “Reserve Title” request message to the primary data store 70. It should be appreciated, that in accordance with an embodiment, the client computer 6 may perform the same determination as discussed above with respect to operation 310, prior to sending the Reserve Title request.
From operation 350, the routine 300 continues to operation 355 where the client applications 34 executing on the client computer 6 receive a response message (i.e., one of the response codes 50) from the primary data store 70 indicating that the Reserve Title request has been granted and that the converted native file 42 will be locked from further editing by other client computers (e.g., the client computer 2). In particular, upon granting the Reserve Title request from the client computer 6, the primary data store 70 may canonicalize the document title 90 to prevent other users (e.g., malicious users) from generating similar titles and have previously determined that the document title 90 (and/or the external identification 92) has not already been reserved by another user. For example, the response message from the primary data store 70 may indicate that the native file 30 (as identified by at least the document title 90) may be reserved for updating.
From operation 355, the routine 300 continues to operation 360, where the client applications 34 executing on the client computer 6 converts the edited/updated native file 30 (not shown) having a proprietary file format to the converted native file 42 having a global file format (i.e., a globally viewable document).
From operation 360, the routine 300 continues to operation 365, where the client applications 34 executing on the client computer 6 send the converted native file 42 to the primary data store 70 as an updated version of the converted native file 32
From operation 365, the routine 300 continues to operation 370, where the client applications 34 executing on the client computer 2 receive the converted native file 42 for viewing. In particular, after the converted native file 42 has been uploaded from the client computer 6 to the primary data store 70, the lock is released thereby enabling the client computer 2 to download the converted native file 42 from the primary data store 70.
From operation 370, the routine 300 continues to operation 375, where the client applications 34 executing on either the client computer 2 or the client computer 6 may periodically resend Reserve Title requests upon receiving a failure message from the primary data store 70. In particular, even when a lock does not prevent a client computer from uploading a file to the primary data store 70, the primary data store 70 may still prevent deny a Reserve Title request under one or more of the following conditions: (1) a maximum number allowed Reserve Title requests has been exceeded; (2) a cookie associated with a requesting client computer is determined to already be in use; (3) a client computer is determined to not be authorized to upload files to the primary data store 70; (4) a client computer has requested to upload a file which has an invalid extension (i.e., a file type that could be used maliciously—such as a .exe file). It should be understood that, in accordance with another embodiment, in addition to periodically resending Reserve Title requests, a client computer (e.g., the client computer 2 or the client computer 6) may additionally also wait until a file is updated before checking with the primary data store 70 (i.e., sending a Reserve Title request) to upload the file. It should further be understood that, in accordance with various embodiments, the primary data store 70 may revoke a Reserve Title request previously granted to a client computer in the event the client computer disconnects from a network connection to the primary data store 70 or because of some other factor, as a result of which, the client computer no longer has rights to update or change a file. From operation 375, the routine 300 then ends.
In particular, the primary data store 70 may generate the ReservedForCreation and ReservedForUpgrade codes when a Reserve Title request is granted for uploading and saving a file to the primary data store 70 as either a new file or an updated version of a file already stored on the primary data store 70. The primary data store 70 may generate the FailedReservedForCreation, FailedReservedForUpgrade, FailedExternalIDLockedForCreate, and FailedExternalIDLockedForUpgrade codes when a Reserve Title request is denied when the requested file is currently locked (i.e., the document title 90 or the external identification 92 have already been reserved by another user). The primary data store 70 may generate the FailedReservationMaxExceeded when a maximum number allowed Reserve Title requests has been exceeded. The primary data store 70 may generate the FailedCookielnUse code when a cookie associated with a requesting client computer is determined to already be in use. The primary data store 70 may generate the FailedNotAuthorized code when a client computer is determined to not be authorized to upload files to the primary data store 70. The primary data store 70 may generate the FailedInvalidExtension code when a client computer has requested to upload a file which has an invalid extension (i.e., a file type that could be used maliciously—such as an .exe file).
Although the invention has been described in connection with various illustrative embodiments, those of ordinary skill in the art will understand that many modifications can be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of the invention in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.