The first good and perhaps still best CollaborativeEditor (there are now many others). It’s demoware, non-open-source, and Mac OS X only. There are no plans to port it to other OSs, but see below for reverse-engineering efforts.

I don’t have Java installed on this computer; I tried to install it once before, and it was a nightmare. shbuf looks neat, but requires a special server to use. (Using some environment that looks cool, but that I’ve never heard of before.)

I believe we have most of the pieces in place to do a crude version fairly quickly.

Use wxPython to make the edit environment. It could just be a text box.

When someone starts editing, send a lock. If they don’t type anything for a second, send a lock release. For every second or two that the lock is in effect, broadcast the contents of the text box.

Cheesy, but- Simple enough, no?

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. But I don’t see why not. I think you can call periodically call “handle_request” rather than “run_forever”, and pick up your mail.

I think the whole magic of the idea is people simultaineously editing without locks. I don’t think there’s any point making one with locks.

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.

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. But whenever two people are editing different places, everything should go smoothly. 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.

Perhaps: Partially version the document. Have the cursor refer to a textual position (index) and a document version. Then intelligently merge changes.

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. 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. 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.

Apparently Rendezvous is one of the key components that SubEthaEdit relied upon. I haven’t looked into it too closely… I think it’s some sort of network discovery service for local networks.. so it may not be too applicable.

Having simultaneous voice communication you need no lock. You just say: “Ok, now you continue at the end, I’ll correct the first paragraph now.” “Ok” says the other one. And then you say nothing for a while, as both of you are working on text.

The approach that was being used by InfoDepot? shortly before its demise was (since it was an outline) to lock just individuals nodes in the document. So different people could be editing different nodes at the same time, each being broadcast simultaneously. (I can’t remember whether the broadcast happened every couple seconds, or when the editor clicked outside the node…)

From Bill Kress Bill.Kress@gmail.com (Not a registered user)

I’d really like to see this app for the PC as well.

Re: locking the document. Shouldn’t be necessary at all.

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.

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).

To solve this worst case race condition:

Thread 1 (Communicaitons): If a change comes from the server a check is run to see if the client has any outstanding edits. If it does (and this edit is not ours), then queue the edit. If not, apply it immideatly.

Thread 2 (Editor thread): The user makes a change. 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”

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. 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).

If there are no packets from other servers in the queue, we are done, just flush the queues. if there are packets from other servers on different lines apply those changes, flush queues, we are done. 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. Done.

This has a few implications:

-Most of the time a single change would come back from the server quickly enough that the result from the server is simply discarded.

-Cursor tracking might be an interesting issue if two people were typing on the same line, but it seems solvable. I can’t imagine an implementaiton that wouldn’t have this exact same problem.

-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.

This seems quite easy. If it’s the communication system that seems hard, I could write that if someone else wants to work on the editor portion. The editor portion would be straight forward under this design, no more complicated than any standard editor with undo queues.

JessRobinson? and I have been working on reverse-engeneering the SubEthaEdit protocol, and implementing a client (in elisp) and server (in perl). Protocol documentation will be appearing at SubEthaEditProtocol?; that’ll link to our code as approps.