1

As I'm sure most of you are aware; tmux and screen have features that allow the sharing of a concurrent terminal session with a remote host.

At first this seems great, and for some purposes it is, but there's one problem: Even though both users (local and remote) are able to send keys and observe the changes live (i.e. simultaneously and in real-time); there's only one cursor. This means that everything is fine as long as only one person types while the other simply observes.

As soon as both users try to type at the same time, they're essentially fighting for control of the keyboard and thus the standard input, and so on.

So while it holds great promise for programmers, etc. as an avenue for real-time collaboration, it ultimately falls short when compared to a web-based solution, of which there is at least one I know of that works great.


What I want to know is:

  • How can the problem be overcome?
  • What considerations need to be taken into account by someone wanting to implement a feature like this (i.e. the potential for each user to have their own cursor, or a similar solution)?
  • Standard terminal-based programs are not designed to accept multiple streams of input, so I think you would need to write programs explicitly with this feature in mind. – Bwmat Aug 20 '16 at 17:21
  • Maybe instead there could be some coordination of who has the ability to provide input at any given time? For example, one of the people collaborating (this could scale to any number of people) would request input control with some key combination, and the person who currently has control would be able to see some indication of that, and release control (when they were ready) with another key combination – Bwmat Aug 20 '16 at 17:23
1

A different approach is the one used by Google Docs. When multiple users work on the same document, every person has her own view of the document and can modify different parts of the document in parallel. The changes are propagated through WebSockets to all users, making it possible to view the changes in real time.

The model itself predates Google Docs by decades and is well known in a particular domain of multiplayer games. You can imagine that the world is a document or a source file, and players can view the world independently of other players, and when one player alters the world, the changes are propagated to other players.

This is essentially what you need here.

A different (and more basic) approach which might work in your case is to have a phone conversation during the programming session; developers would simply agree on who is taking the commands, and the other person is not expected to type or move the cursor, unless both persons agree.

  • Same thing with HackPad, except it's open source so you can run it locally. – 9000 Jul 21 '16 at 18:19
0

How can the problem be overcome?

Unless you are willing to write your own text editor or shell solution, I hardly see how you can overcome the problem unless you simply instaure a protocol of some sort that would simply forbid concurrent access (but also forbid concurrent collaboration). The best I can imagine would be a split screen setup, each client in his screen which would be OK for tty pair programming, but I don't know if tmux supports it. Some resource on the matter : http://www.hamvocke.com/blog/remote-pair-programming-with-tmux/

What considerations need to be taken into account by someone wanting to implement a feature like this (i.e. the potential for each user to have their own cursor, or a similar solution)?

It's a bit vague, but I guess you have to implement a client/server scheme anyway ; doing it as a web scratch makes sense because you instantly benefit of GUI, copy/paste/undo local to each client. Then you have to wire it with system tools sucha as a git, laguage compiler/intepreter...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.