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

"collaborative editing" clarification Was: New features to vote on and sponsoring

Expand Messages
  • Yakov Lerner
    Hello Bram, ... in a second I d like to ask for some clarifications. Clarification about perceived behaviour, not about implementation: 1. two-way
    Message 1 of 3 , Feb 3, 2008
    • 0 Attachment
      Hello Bram,
      You wrote:
      > add collaborative editing: changes made to a buffer show up in another Vim in a second

      I'd like to ask for some clarifications. Clarification about
      perceived behaviour, not about  implementation:

      1. "two-way collaboration" or "one-way collaboration" ?

      Vim instance B attaches to instance A for collaboration
      on file F. Then B absorbs (and shows) changes to F made by A, right ?

      Does it automatically work the opposite way ? That is, when B's user
      makes changes, will A also show these changes so that they always stay in sync ?

      Which operation mode will be the basic mode ? The two-way or the one-way ?
      Do we allow both modes of operation ?

      In two-way collab, two swapfiles file will coexist for the same edited file, right ?

      2. Relation of "collaborative editing" to "client-server"
      Does "collaborative editing" *require* client-server ?
      Can "collaborative editing" work *without* client-server ?
      I see this item as matter of requirements, not nevessarily as matter of implementation.

      3. We want to allow more than two Vims atached to the collaboration group, correct ?
      (N-way collaboration).

      Is the collaboration group "symmetric" (every instance plays identical role; absorbs changes of all others, can make changes which all others absorb) ?
      Or it has one "central" instance which has special role in the group ? (say, only "central" instance makes changes;  all other instances cannot make their own changes; peripheral instances absorb only changes of the "central" instance).

      4. You see the simple implementation of collaboration as vim-B
      reading swapfile of vim-A, correct ? Does it lend itself to two-way
      collaboration ?  To the N-way collaboration ?

      Yakov


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---

    • Richard Hartmann
      ... Yes. ... Yes. ... N-way should be default, the other should be trivial to add once n-way is implemented. ... I would assume that one VIM instance would be
      Message 2 of 3 , Feb 4, 2008
      • 0 Attachment
        On Feb 4, 2008 6:19 AM, Yakov Lerner <iler.ml@...> wrote:


        > I'd like to ask for some clarifications. Clarification about
        > perceived behaviour, not about implementation:

        Assuming you want both Bram's and community feedback, here goes:


        > 1. "two-way collaboration" or "one-way collaboration" ?
        >
        > Vim instance B attaches to instance A for collaboration
        > on file F. Then B absorbs (and shows) changes to F made by A, right ?

        Yes.


        > Does it automatically work the opposite way ? That is, when B's user
        > makes changes, will A also show these changes so that they always stay in
        > sync ?

        Yes.


        > Which operation mode will be the basic mode ? The two-way or the one-way ?
        > Do we allow both modes of operation ?

        N-way should be default, the other should be trivial to add once n-way
        is implemented.


        > In two-way collab, two swapfiles file will coexist for the same edited file,
        > right ?

        I would assume that one VIM instance would be the master, so while both
        keep copies, that one would be the one to use if there are conflicts.
        The other possibility is a fully meshed, democratic editing process.
        That would require everyone to have their own swapfile, though merging
        changes etc is non-trivial and would probably be a feature in itself
        (unless you just load the swap and diff the collab file, that is).



        > 2. Relation of "collaborative editing" to "client-server"
        > Does "collaborative editing" *require* client-server ?
        > Can "collaborative editing" work *without* client-server ?
        > I see this item as matter of requirements, not nevessarily as matter of
        > implementation.

        There are four basic possibilities:

        1) tree with a depth of 1

        2) tree with a depth of n

        3) fully connected graph

        4) partially connected graph

        For reasons of scalability and usefulness, either 1 or 4 seem to be the
        viable options, to me. 4 opens several cans of worms, 1 is pretty
        straightforward & should cover 99% of all use cases.


        > 3. We want to allow more than two Vims atached to the collaboration group,
        > correct ?
        > (N-way collaboration).

        Yes.


        > Is the collaboration group "symmetric" (every instance plays identical role;
        > absorbs changes of all others, can make changes which all others absorb) ?
        > Or it has one "central" instance which has special role in the group ? (say,
        > only "central" instance makes changes; all other instances cannot make
        > their own changes; peripheral instances absorb only changes of the "central"
        > instance).

        If the server (assuming case 1) could assign roles, that would probably
        be best & the easiest to use. If I set you to be able to edit the file,
        good. If I set you to only watch what I do, tough luck.


        > 4. You see the simple implementation of collaboration as vim-B
        > reading swapfile of vim-A, correct ? Does it lend itself to two-way
        > collaboration ? To the N-way collaboration ?

        You mean that the VIM instances send each other updated copies of their
        respective swap files, all the time? That is probably not a good idea. I
        would rather go farther in the way of a headless VIM that gets updates
        from local or remote interaction clients. That would enable easy GUI
        versions like KVim, as well. I am aware that this is a truckload of
        worms, though :/
        On the other hand, that solution would solve several problems, at once.


        One thing that would be nice to have is a way to lock your own cursor to
        anyone else's or to have your own cursor to do stuff with. Collab vs
        teaching, so to speak.


        Best regards,
        Richard

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... collaborative implies that people work together. Probably N-way. Possibly with some restrictions (people may be able to join in read-only mode). Also
        Message 3 of 3 , Feb 4, 2008
        • 0 Attachment
          Yakov Lerner wrote:

          > Hello Bram,
          > You wrote:
          > > add collaborative editing: changes made to a buffer show up in another Vim
          > in a second
          >
          > I'd like to ask for some clarifications. Clarification about
          > perceived behaviour, not about implementation:
          >
          > 1. "two-way collaboration" or "one-way collaboration" ?
          >
          > Vim instance B attaches to instance A for collaboration
          > on file F. Then B absorbs (and shows) changes to F made by A, right ?
          >
          > Does it automatically work the opposite way ? That is, when B's user
          > makes changes, will A also show these changes so that they always stay in
          > sync ?
          >
          > Which operation mode will be the basic mode ? The two-way or the one-way ?
          > Do we allow both modes of operation ?
          >
          > In two-way collab, two swapfiles file will coexist for the same edited file,
          > right ?

          "collaborative" implies that people work together. Probably N-way.
          Possibly with some restrictions (people may be able to join in read-only
          mode).

          Also that when you start Vim on a file at home, you can continue working
          on it from work and then on your laptop in Starbucks. Without getting
          "swap file exists" errors.

          I can't say anything about the implementation. Figuring this out is
          part of the work. It requires votes before thinking about this.

          --
          Our job was to build a computer information system for the branch banks. We
          were the perfect people for the job: Dean had seen a computer once, and I had
          heard Dean talk about it.
          (Scott Adams - The Dilbert principle)

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ download, build and distribute -- http://www.A-A-P.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.