Maybe they could incorporate this concept into Git itself? :-) Sort of a realtime updated Git repository? But wait, I thought that one of the advantages of an offline Git repository is that you can work if the line goes down. What sort of re-synchronization process does this have in case a few of the realtime sockets fail?

I don't work on these things except as mathematical abstractions in my mind. :-)

After seeing how jquery and ajax work, I beginning to believe that eventually we all will be running these supposedly non-blocking event-loop programs, in all our software, javascript will have won in the end. Every square inch of our screens will be controlled by 1 event-loop or another, dealing with their own sockets. It's called Web 2.0 I believe. :-)

But if I was working on it, I would ponder how to resynchronize after a communications failure. Like would the histories of all changes, which occurred during the down time, be replayed for the benefit of the central repository tree.

I was recently watching a youtube of Linus Torvalds, and he said essentially that realtime central systems are not good. Everyone should run independently and update each other on a regular basis.

Another thing Torvalds talked about, was the way that in Git, the node names are the actual md5sums of the diff data in the node. This assures perfect replication... what comes out is what went in, or error flag.

But these are just the ramblings of someone having a good christmas. :-)