"collaborative editing" clarification Was: New features to vote on and sponsoring
Yakov Lerner
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
Richard Hartmann
> 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
Bram Moolenaar
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 -- Br...@Moolenaar.net -- 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 ///