On Tuesday 02 August 2005 04:13 pm, mental@...3... wrote:
Could you elaborate on the difficulties you are experiencing?
-mental
Sure thing -- I probably should have done that in the original message...
Client synchronization in Inkboard currently functions like this. Given two users A and B:
1. A sends a request response to B. 2. B receives the request response, clears all definitions, layers, and metadata, and sends a positive acknowledgement to A. 3. A receives the acknowledgment from B, sends a DOCUMENT_BEGIN signal to B, and begins to send the document. 4. After A has sent the entire document to B, A sends a DOCUMENT_END signal. 5. After B processes the DOCUMENT_BEGIN signal, B begins processing incoming messages and applying the changes to the document tree. 5. After B processes DOCUMENT_END, B clears its undo/redo stacks.
B does not process changes as it receives them: it queues up incoming messages and then processes messages periodically. An Inkboard client keeps track of the current sequence number for each client it knows about (via chatroom or user-to-user conference), and will refuse to process messages that appear to arrive late (i.e. have a sequence number smaller than the latest one processed). This will result in problems with m
The calls to sp_document_clear_undo and sp_document_clear_redo in step (5) have been inserted at around line 125 of src/Jabber_whiteboard/message_processors.cpp.
If I'm understanding the undo/redo mechanism properly, this sequence of actions should result in the desired behavior: A and B with a synchronized document and B unable to revert to the pre-synchronization point. However, when I synchronize A and B and immediately run an undo operation on B, I can recover the point immediately after B cleared its document in step (2), which results in an unusable document.
-- David