CONDITIONAL INSERT OR MERGE IN A
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to data conferencing systems, and, in particular, to mechanisms for providing for conditional insert or merge of data annotations in a data conferencing application.
2. Description of the Related Art
In data conferencing systems, there is a need for synchronization of distributed data in the conference. In data conferencing systems such as teleconferencing systems, a plurality of users are provided with the ability to have an electronic on-line meeting even if the users are not physically in the same room or building. Using such application programs, modern communication systems have enabled the ability to have a "meeting" wherein all users participate in the meeting through their individual computer systems and share data, graphics, text, and other types of information. Users may communicate with one another, sharing data in the form of graphical images, text, or other "annotations" and other information represented on the computer system display. This is analogous to a meeting where participants in a face-to-face meeting may display information to one another on a whiteboard and other participants may add annotations, delete, or otherwise modify the board. In some usages, video data may also be shared among a plurality of connected users during such teleconferences, or video conferences.
One of the requisites of an electronic conferencing system is the need to replicate the same data on all users' displays participating in the conference. Such systems typically implement this capability in a variety of ways. The most common is the client/server model wherein a single connected node acts as a "server" of other nodes in the system and the remaining nodes connected in the conference act as slaves or clients to the server process. Thus, each of the clients merely receive data from the central machine to update their displays. Such systems, however, are entirely dependent upon the service being provided by the server and the throughput of the communication medium. Systems wherein the clients merely act as displays and inputs for user requests suffer from severe performance problems due to resulting updates of data from the server, which is typically handled serially by the server.
Another prior art solution for maintaining as synchronous all of a participant's display in a conferencing system relies on a distributed client/server system. In such a system, a shared object structure is kept on the server and clients are made aware of changes of that distributed information through alerts or demons. The disadvantage of this approach is the reliance on the architecture itself. This includes a data conferencing application which must be able to connect several users over a phone line from point to point without requiring access to a centralized common server.
In the client/server approach, moreover, performance suffers greatly because requests to add or delete objects such as annotations, graphical images, or other information on a participant's display is entirely dependent upon communication from the server. Thus, real-time performance severely suffers in prior art client/server models since approval to act upon and manipulate objects on a participant's display is entirely dependent upon a whole set of dependent variables such as the number of requests to the server pending, the throughput of the communication medium, the number of participants connected, and the like.
Yet another prior art approach for maintaining the synchronousness of a plurality of participants in a conferencing system is the use of a distributed object-oriented system. This is a generalized approach which relies upon extensions,
5 in one prior art solution, of the SmallTalk language itself. In this prior art system, "local" objects send messages to "proxy" objects which are local representatives for objects in the "shared" object space. The proxy objects communicate with the real objects through an RPC (Remote Proce
10 dure Call) mechanism. RPC is a protocol governing the method with which an application activates processes on other nodes and retrieves the results. Such a conventional mechanism is defines by Sun Microsystems, Inc. and described in RFC-1057 that provides a standard for initiating
15 and controlling processes on remote or distributed computer systems.
The problem with this approach is in its generality which requires extensive support for sharing any object while making no assumptions about the behavior of objects. This
20 has two disadvantages. First, a complete "SmallTalk system" is needed to support the distribution of objects in general. Second, the concurrency problem for any object is difficult because multiple participants may have different objects in their systems and such different objects may not
25 be able to be communicated to the remaining users.
Yet another of the disadvantages of prior art data conferencing systems is their mechanism for supporting the transfer of very large blocks of information. Typically, such systems have relied upon point-to-point communication
30 schemes wherein individual nodes such as the server, in the client/server model, must transmit the information from one individual node to the server and then from the server to the remaining participants' systems. Also, the transfer of very large pieces of data, such as files and/or images or other data,
35 consumes a relatively large amount of resources in the system and bandwidth of the communication medium. Thus, prior art conferencing systems suffer from severe performance difficulties caused by the amount of data which may be transmitted within the system during a teleconference.
40 During a distributed data conference, conference objects are replicated on all nodes in object stores and must be kept synchronous to ensure that each user's view and conference objects are identical. An arbiter object may be utilized to synchronize the distributed data for this purpose. One such
45 technique is taught in U.S. patent application Ser. No. 08/137,320, filed Oct. 14, 1993. now issued as U.S. Pat No. 5,408,470. entitled "Deferred Synchronization of Distributed Objects," the entirety of which is incorporated herein by reference. In such arbitration schemes, the arbiter object
50 is used to schedule changes to various objects instantiated on various nodes of the conference, for example adding, moving, or merging pages or other object stores, and the like. The arbiter object thus acts as a synchronization point, but if the arbiter node is busy waiting for an operation to
55 complete, which is necessary since a distributed data conference has asynchronous events, then other requests that require arbitration will be blocked until the arbiter object is free to schedule these requests. Another problem that can arise in a distributed data
60 conferencing system occurs when two or more users perform simultaneous, conflicting actions. If one user had first annotated the blank screen, then a new page with the first annotation would be created and distributed to the conference application of the other user's node. Then if the second
65 user a short time later began a second annotation, the second annotation would be added to the page, and the second annotation distributed to all other nodes on the network.