On 4/08/19 8:20 AM, Chris Angelico wrote:
On Sun, Aug 4, 2019 at 4:46 AM Terry Reedy <tjre...@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
--
https://mail.python.org/mailman/listinfo/python-list
