Lines (or paragraphs) would probably need some permanent numbering scheme to insure that an insert or delete in one place did not effect the locations of everything beneath it. I can’t imagine an implementaiton that wouldn’t have this exact same problem. Cursor tracking might be an interesting issue if two people were typing on the same line, but it seems solvable. Most of the time a single change would come back from the server quickly enough that the result from the server is simply discarded. If there are packets from other servers on the same line, then: Undo everything in the undo buffer Apply the changes in the queue (this will also re-create all the changes you just undid) Flush the buffers. if there are packets from other servers on different lines apply those changes, flush queues, we are done. If there are no packets from other servers in the queue, we are done, just flush the queues.
This implies that it is up-to-date with the server (Even if there are outstanding packets from other sources, they can be taken care of after this synchronization is done).
Now the client waits until the packet at the end of the queue has the same sequence number as the last one it sent out. The client creates a change notification packet with a sequence number The client sends the change notification to the server The client places the change notification into an “Undo buffer” Thread 2 (Editor thread): The user makes a change. If it does (and this edit is not ours), then queue the edit. Thread 1 (Communicaitons): If a change comes from the server a check is run to see if the client has any outstanding edits. The race condition is when two people are typing on the same line at the same time, otherwise it’s a no-brainer (Assuming the location of each change can be located exactly). If you assume a centralized server (simply be a listener port opened on the first PC to open the doc-Although a dedicated server immune to firewalls might not be a bad idea), you can assume that everybody receives the modifications in order, and that if they apply those modifications the result would be that everyboy has the same document. I’d really like to see this app for the PC as well. Then when updates come in from B’s computer, it knows how much to add or subtract from the stated cursor position to get the true cursor position. The document object keeps track of the offset between what B’s computer thinks its cursor offset is, and what it actually is at the current time. Probably better: When person A’s cursor is above person B’s, adding or removing text at A’s location will affect the numerical index of B’s cursor. Have the cursor refer to a textual position (index) and a document version. We need to handle the case where one person suddenly pastes in a large chunk of text, affecting the numerical position of everything else in the document. But whenever two people are editing different places, everything should go smoothly. It is forgivable if when two people’s cursors almost overlap, or when they cross over each other, there is some confusion due to lags. Seems to me the thing to do is use some sort of distributed object middleware like ICE, and then have a object for the document, and an additional “cursor” object for each person. I don’t think there’s any point making one with locks. I think the whole magic of the idea is people simultaineously editing without locks.
Or,… well, there’s a ton of ways to write this one. I think you can call periodically call “handle_request” rather than “run_forever”, and pick up your mail. I don’t know enough about IntComm: XmlRpc on Python to know if I can simultaneously run a server, send out requests, and maintain a functioning GUI. For every second or two that the lock is in effect, broadcast the contents of the text box. If they don’t type anything for a second, send a lock release. When someone starts editing, send a lock.
0 kommentar(er)
