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
