On Sun, Apr 29, 2007 at 10:43:14PM +0200, Bram Moolenaar wrote: > > Yakov Lerner wrote: > > > Is it possible to add this item to the vim voting list ?: > > > > "collaboration of N vim instances editing same file" > > -- Ability of N instances of vim to absorb, merge and show changes > > to the same file made by other running vim instances [ either by reading > > other vim's swapfiles, or somehow else ] ? > > It's an interesting idea. Won't be easy to implement in such a way that > it works on most platforms.
I think the hard part will mostly have to do with design/policy choices. How is a session instigated? Does a single instance "own" the file and other instances join? Or maybe there should be some server that fronts a repository (e.g. svn, plain filesystem, WebDAV, etc.)? Or does it use svn (or WebDAV, or other network fileshare) for everything, including discovery, authentication, and inter-vim communication? What kind of protocol should be used? It will be at least partially homegrown, but is there a standard on which it should be based (perhaps there is a standard for recording document edits beyond just diffs, I don't know)? Should communication be over a star network of reliable (i.e. TCP) connections? A mesh? A hypercube? A minimum spanning tree? Should it be, instead, unreliable (i.e. UDP) multicast (which makes discovery easy and authentication a separate protocol)? None of these questions involve platform-specific issues, since they all assume that communication will be over TCP/IP, but I don't think they have easy answers. It mostly comes down to what problem you are trying to solve. Some sample scenarios: - allow a few (<5) open source developers work on the same source file, which has its primary existence in a subversion repository to which they all have write access, collaboratively across the net - allow developers (<5) in the same company work collaboratively on a source file over their company LAN - allow massive numbers of people collaborate on some literary art project (e.g. a collaborative novel, something Wikipedia-like) - provide a teleconferencing system for a few writers and a large number of readers across the net (e.g. teaching aid, "watch Bram code Vim" promotion) - two, and only two, developers working together over a fast network - allow a small group (<10) collaborators develop the Next Big Thing for their startup, despite each developer living in a different city Each one implies different choices. If it's over the open net, authentication and security are concerns, at least for writers. If non-writers are allowed to spectate, you need some sort of permissions system. Over the open net there needs to be some handling of timeouts and lag. Smaller numbers of participants lets you cut corners in ways that larger numbers of participants do not. Editing sensitive data (e.g. the next Harry Potter, if J.K. Rowling used Vim and collaborated directly with another author or with her editor) requires encryption over the network, not to mention strong authentication. Making something that serves all these needs is a massive undertaking, but since Vim gets used in all sorts of environments, which scenario(s) do you choose? > It will probably require a server to make it possible for various Vim > instances to find each other. And to take care of authentication. > Perhaps such a server already exists? [...] As far as I know, the first implementation of this sort of idea to gain real traction among users of text editors (i.e. largely developers) is SubEthaEdit <http://www.codingmonkeys.de/subethaedit/collaborate.html>. It uses MacOS X's Bonjour (which is an implementation of ZeroConf, see http://developer.apple.com/opensource/internet/bonjour.html for Apple's BSD-licensed implementation) for discovery. I'd be inclined to go with the single instance owning the file and announcing itself via ZeroConf, but I think even that requires either requiring a particular ZeroConf implementation on the system or juggling carefully which vim instance is responding to DNS requests. It also plays no part in authentication. Another alternative is to skip discovery and require some out-of-band communication (e.g. IM, phone call, etc.) to communicate the host and port to connect to. Of course, that makes authentication easy since the same out-of-band communication can be used to give a password. No, that isn't what you'd call strong authentication or good security, but it's probably good enough for most people. Of course, your communication protocol should be encrypted... Authentication is prickly and I'm not sure how you'd choose what authentication methods should be allowed (and implemented). Again, it falls under the question of which scenario(s) we intend to serve. I'll point out that this sort of thing is what first-person shooter network play has been about since Doom first came out way back when. At the time, the solution was to broadcast every keystroke (over IPX, yet) and have each game instance interpret the keystrokes for the benefit of each virtual player. It might be instructive to look into how something like Quake3 does things. > /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ --Greg