Loading ...
Sorry, an error occurred while loading the content.
 

Re: wish: collaboration of N vim instances editing same file

Expand Messages
  • Gregory Seidman
    ... 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
    Message 1 of 7 , Apr 29, 2007
      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 -- Bram@... -- http://www.Moolenaar.net \\\
      --Greg
    Your message has been successfully submitted and would be delivered to recipients shortly.