On Feb 4, 2008 6:19 AM, Yakov Lerner <iler.ml@...
> 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 ?
> 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 ?
N-way should be default, the other should be trivial to add once n-way
> 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
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).
> 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"
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.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php