Prototypical Multi-User Feature

[Jens-Wolfhard Schicke-Uffmann]

Hi,

because I had immediate use for it, I implemented
a prototype of the much requested (IIRC) multi-user feature:
https://github.com/Drahflow/vim-multiuser/

To try:

Shell 1:
% vim --multiuser-server # opens listening socket on port 9999

Shell 2 to N:
% vim
:set remote=127.0.0.1:9999


It essentially cuts into the ml_append / ml_delete interface
and forwards the changes to a central master document on a server,
keeping track of various versions of line-numbers in the process.

The remote option is buffer local and logically replaces the current
file contents with the server document contents (which are initially empty).


TODO
* Documentation
* Only os_unix, HAVE_SELECT correctly polls the network socket
* Error reporting and handling is very missing
* The code organization should be improved
* Marks, folds and cursors in other windows are not yet adjusted (but it's clear how this can be done)
* Adjust buffer change/needs-write/etc. logic at various places
* Enable initial upload (currently, please use :r to load a file into the server)
* Figure out various still unknown edge-cases

Is there a realistic chance to get it accepted upstream?
If so, what other things should I keep in mind before producing a patch?

Sincerely,
Drahflow

[Ben Fritz]

On Thursday, June 26, 2014 8:18:51 AM UTC-5, Drahflow wrote:
> Hi,
>
>
>
> because I had immediate use for it, I implemented
>
> a prototype of the much requested (IIRC) multi-user feature:
>
> https://github.com/Drahflow/vim-multiuser/
>
>

Can you explain a little what a "multi-user feature" is? Is this simultaneous editing of the same buffer by multiple people (a.k.a. collaborative editing)?

[Jens-Wolfhard Schicke-Uffmann]

On Thu, Jun 26, 2014 at 07:12:30AM -0700, Ben Fritz wrote:
> On Thursday, June 26, 2014 8:18:51 AM UTC-5, Drahflow wrote:
> > a prototype of the much requested (IIRC) multi-user feature:

> Can you explain a little what a "multi-user feature" is? Is this
> simultaneous editing of the same buffer by multiple people (a.k.a.
> collaborative editing)?

Yes. It is the simultaneous editing of the "same" buffer by multiple
people connected via TCP/IP networking. (Technically, these are
obviously still separate buffers (they are on different machines after
all), they just seem to have the same content all the time.)

Sincerely,
Drahflow

[Christian Brabandt]

Hi Jens-Wolfhard!

I have no definite answer, but of course fix as many bugs as possible
and reduce the number of TODO items. I think it also should be available
on any platform, not only Unix (or at least also on Windows besides
Unix).
If possible write a test and perhaps make is only available with a
certain FEAT_ macro.

Having said that and considering, there is a chance that it might be
included sometimes. But you need to be very patient.(The breakindent
patch was just included after floating around for several years). So be
patient (look at the todo list) and try to react to any issue that is
addressed here.

Best,
Christian

[Bram Moolenaar]

It is very unlikely I will include half a solution.
You need to take care of authentication, for example.

One thing would be awesome: To have a cross-platform collaboration edit
mechanism that works will several editors. One that only works with Vim
will be limited in worldwide acceptance.

Google Drive offers something that might work. The mechanism is working
very well, at least for Google documents. Problem is that the library
is only available for JavaScript. So it would require embedding a
JavaScript interpreter in Vim. It's not impossible...
https://developers.google.com/drive/realtime/

There is an example editor: Neutron Drive:
http://googledevelopers.blogspot.ch/2013/03/build-collaborative-apps-with-google.html

--
ARTHUR: Then who is your lord?
WOMAN: We don't have a lord.
ARTHUR: What?
DENNIS: I told you. We're an anarcho-syndicalist commune. We take it in
turns to act as a sort of executive officer for the week.
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Jens-Wolfhard Schicke-Uffmann]

Hi Bram,

On Thu, Jun 26, 2014 at 11:08:30PM +0200, Bram Moolenaar wrote:
> You need to take care of authentication, for example.

Good point, thanks.

> One thing would be awesome: To have a cross-platform collaboration edit
> mechanism that works will several editors. One that only works with Vim
> will be limited in worldwide acceptance.
>
> Google Drive offers something that might work. The mechanism is working
> very well, at least for Google documents. Problem is that the library
> is only available for JavaScript. So it would require embedding a
> JavaScript interpreter in Vim. It's not impossible...
> https://developers.google.com/drive/realtime/

This would bind VIm to an API which has a proprietary server
implementation, something I'd rather avoid.

However, I think that EtherpadLite offers a protocol I could implement
and which should work well. Unless someone stops me, that would be the
one I'll be aiming for then.

Regards,
Drahflow

[Bram Moolenaar]

Jens-Wolfhard Schicke-Uffmann wrote:

> Hi Bram,
>
> On Thu, Jun 26, 2014 at 11:08:30PM +0200, Bram Moolenaar wrote:
> > You need to take care of authentication, for example.
> Good point, thanks.
>
> > One thing would be awesome: To have a cross-platform collaboration edit
> > mechanism that works will several editors. One that only works with Vim
> > will be limited in worldwide acceptance.

> >=20

> > Google Drive offers something that might work. The mechanism is working
> > very well, at least for Google documents. Problem is that the library
> > is only available for JavaScript. So it would require embedding a
> > JavaScript interpreter in Vim. It's not impossible...
> > https://developers.google.com/drive/realtime/
> This would bind VIm to an API which has a proprietary server
> implementation, something I'd rather avoid.
>
> However, I think that EtherpadLite offers a protocol I could implement
> and which should work well. Unless someone stops me, that would be the
> one I'll be aiming for then.

There is a Python implementation for etherpad lite, so that would make
things much simpler.

I have no idea how well etherpad lite works and how good the security
is. It does appear to be possible to run your own server or use an
existing one on the Internet.

--
Courtroom Quote #19:
Q: Doctor, how many autopsies have you performed on dead people?
A: All my autopsies have been performed on dead people.

[Guyzmo]

Hello,

On Sat, Jun 28, 2014 at 03:50:10PM +0200, Bram Moolenaar wrote:
> Jens-Wolfhard Schicke-Uffmann wrote:
> > On Thu, Jun 26, 2014 at 11:08:30PM +0200, Bram Moolenaar wrote:
> > > You need to take care of authentication, for example.
> > Good point, thanks.
> > > One thing would be awesome: To have a cross-platform collaboration edit
> > > mechanism that works will several editors. One that only works with Vim
> > > will be limited in worldwide acceptance.
> > >=20
> > > Google Drive offers something that might work. The mechanism is working
> > > very well, at least for Google documents. Problem is that the library
> > > is only available for JavaScript. So it would require embedding a
> > > JavaScript interpreter in Vim. It's not impossible...
> > > https://developers.google.com/drive/realtime/
> > This would bind VIm to an API which has a proprietary server
> > implementation, something I'd rather avoid.
> > However, I think that EtherpadLite offers a protocol I could implement
> > and which should work well. Unless someone stops me, that would be the
> > one I'll be aiming for then.
> There is a Python implementation for etherpad lite, so that would make
> things much simpler.
> I have no idea how well etherpad lite works and how good the security
> is. It does appear to be possible to run your own server or use an
> existing one on the Internet.

I have prototyped an etherpadlite python library and a vim plugin as
an example of how to use it, I've sent a mail on the list about a year
ago about that, so I guess that's what you're talking about, Bram:

https://github.com/guyzmo/PyEtherpadLite
https://github.com/guyzmo/vim-etherpad

As far as I've gone, it's working perfectly well as "read-only", and
it sometimes work when sending changesets, but fails too often to
consider the code base stable.

I've tried making it as good as I could, but failed in my attempts
to make it actually *good*. The main problem is that the OT library
being used by EPL is unpacking the changeset and rebuilding the
changeset, even if valid, if the rebuilt changeset is not the same as
the unpacked changeset, it will refuse the changeset.

Another thing is that EPL is not a text editor, it's a text
processor, because it implements rich text features that we don't
want to see exist in vim. Bold, Italic, underlined… and I don't even
talk about how messy are the bullet points.

I've been considering to actually load that JS library from python
to build the changesets… But honestly, what stopped me was thinking
the level of complexity I'd then be creating, JS over Python over
Vim… Then could we still joke about emacs being heavyweight? :-) Or
maybe, there's a way to convert JS code into python bytecode? (Pyjon?)

Anyway, please fork and improve on my code! I'm always around
(mail, Jabber, IRC – zmo on freenode, just ask!) to help, and always
happy to accept patches! If we all join forces, we may make actually
vim connecting to EPL a reality for everyday use.

Cheers,

--
Guyzmo