Changes between Version 3 and Version 4 of Infinote/Protocol
- Timestamp:
- 09/25/07 20:10:29 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Infinote/Protocol
v3 v4 3 3 Please note: This document is by no means complete. Comments appreciated. 4 4 5 TODO: Formatting...5 TODO: Session example(s) 6 6 7 7 TODO: List error domains and codes … … 30 30 * Synchronization-Only: A session can be synchronized to a client without the client subscribing to the session. 31 31 * No-User-Subscription: A host can subscribe to the session without joining a user (and therefore unable to modify the document). This is read-only access, in fact. 32 * Multiple-User-Subscription: When subscribed, a host can join multiple users into the session. This allows a client to act as a proxy for more clients that can connect to the proxy but not to the "real" server.32 * Multiple-User-Subscription: When subscribed, a host can join multiple users into the session. This allows a client to act as a proxy for more clients that only can connect to the proxy but not to the "real" server. 33 33 34 34 == XMPP == … … 431 431 The state of a document is completely defined by a so-called state vector specifying how many operations each user did. For example, if user A made 2 requests and user B made 3 requests, the document has a certain state. All users that processed these 5 requests are in the same state. Note that it does not matter in which order the requests are processed (as long as the causal order is kept), which is the key concept behind the adOPTed algorithm. 432 432 433 Each user maintains a state vector for each user that describes in which state that user is. This vector is updated every time a request is received from a particular user. This requires every user to send no-op requests if it has been inactive for some time, so that othersknow the state of this user.433 Each user maintains a state vector for each other user that describes in which state that user is. This vector is updated every time a request is received from a particular user. This requires every user to send no-op requests if it has been inactive for some time, so that others still know the state of this user. 434 434 435 435 Also, each user maintains a request log in which all requests the user made are stored. This is required for transforming incoming requests from other users that were made in a different state of the document. Details to the adOPTed algorithm and how these transformations are performed can be found in the papers at http://portal.acm.org/citation.cfm?id=240305 and http://portal.acm.org/citation.cfm?doid=320297.320312. … … 452 452 453 453 {{{ 454 <sync-state time="time" />455 }}}456 457 * time, StateVector: The current state vector.458 459 Tells the state vector of the state the document currently is in.460 461 {{{462 454 <sync-request user="user_id" time="time"> 463 455 <operation /> … … 491 483 492 484 * user, Integer: The ID of the user that made the request. 493 * time, State Vector : The document state at which the request was made.485 * time, State Vector diff: Describes the document state at which the request was made. 494 486 * operation: The operation performed by the request, see below. 495 487 496 Whenever a user issues a request the <request> message is sent. The user must have joined via the connection the request message comes from. <request> is sent to the whole subscription group. 488 Whenever a user issues a request the <request> message is sent. The user must have joined via the connection the request message comes from. <request> is sent to the whole subscription group. The time sent with this message is not absolute, but relative to the time from the last request of this user. For, example, if time contains the value "2:3;1:1", this means that since the last request of that user, it processed 3 requests from user 2 and one request from user 1. Note that the value for the user itself is therefore always zero, because there cannot be any requests inbetween them. This requires the requests from some user to arrive in-order, but it state vector components from inactive (or users that have left the session) need not to be transmitted all the time. 497 489 498 490 === Operations === … … 500 492 There are two types of operations. Such operations that modify the document and such that do not. For example, inserting a character into the document does modify it, but moving the cursor of a user does not. If the operation of a request does not modify the document, the request is not recorded in the request log. 501 493 502 The following operations are defined 494 The following operations are defined: 503 495 504 496 {{{