Remote/Pair-Programming in-the-cloud

[DL Neil]

On 4/08/19 8:20 AM, Chris Angelico wrote:
> On Sun, Aug 4, 2019 at 4:46 AM Terry Reedy <tjreedy at udel.edu> wrote:
>> On 8/3/2019 1:50 AM, Chris Angelico wrote:
>> Since master and clone are copies of the same program, switching roles
>> should be simple, and easier than trading seats.
> 
> Should be indeed, though having accidentally painted myself into a
> corner on many occasions, I would say it's worth writing this down as
> a goal all the same :)

+1
Done!


>>> However, I think it would be an extremely useful feature if the output
>>> from running the program could also be replicated to the other client.
>>> Let's say you're developing a Python script that connects to a
>>> database (eg psycopg2 + PostgreSQL). To run that locally, you'd need
>>> your own replica of the database, and that often means having your own
>>> credentials (ie having the script able to choose which set of
>>> credentials to use), replicating the database schema, and possibly
>>> even getting a duplicate of the current table contents. Way WAY easier
>>> to just run it on one computer and copy the output.
>>
>> I did not think of this scenario because I don't currently program with
>> external libraries and DBs.  Sending output seems to be a must, with
>> running delivered code an option depending on trust and code review.  It
>> does, however, require a control message to switch incoming text from
>> editor to shell.
> 
> Rather than having such a control message, perhaps it could be
> possible to have any number of "target window" channels? So you could
> have two editor windows and a shell, or even multiple shells, if Idle
> can do that in one process. I'm not sure how Idle's architecture is;
> in my experimentation, I was only able to get a single execution
> window.

A chat window? (yes, multiple tabs, or panels, or a floating window)
An audio channel?


>> I believe bittorrent somehow deals with the issue, but I don't know how
>> much a broker is used after the initial seeding.  I believe some
>> player-hosted multiplayer games run peer-to-peer after the initial
>> introduction, but I don't know for sure.
> 
> Hmm, bittorrent's broker is just for finding peers - it doesn't
> actually transfer any content. I'm pretty sure two behind-NAT torrent
> clients are unable to communicate unless one of them has a port
> forwarded to it.
> 
>> Restriction to local networks might have some use.  There have been
>> programming classes where a teacher uses IDLE projected on an overhead
>> screen.  In at least some cases, a large type size (25-40) is needed.
>> It might be nicer to deliver to each students computer.
> 
> The easiest way would be to have the main Idle engine able to listen
> on a socket OR connect to one, and then "restricting to LAN" is simply
> a matter of managing it in your firewall (or, in the case of many NAT
> networks, simply a matter of doing nothing).
> 
> The broker would be a basic echo server, and if desired, it could
> handle encryption (TLS). Since there would potentially be many
> concurrent Idle replications happening, there'd need to be some sort
> of "room name" or something, but it could still be very simplistic.
> 
> This would be a very cool feature, especially since it could bring
> ultra low latency pair programming even to people on mobile
> connections.

+1
(don't forget those of us whose "high speed broadband" still falls well 
short of the promised "information super highway"!)
-- 
Regards =dn