The "loop and a half"

Peter J. Holzer hjp-usenet3 at hjp.at
Mon Oct 9 03:06:04 EDT 2017


On 2017-10-09 04:35, Mikhail V <mikhailwas at gmail.com> wrote:
> Just for people like me who know nothing about networking,
> can you popularly explain the :
>
>> Have you ever worked on a slow remote session where a GUI is
>> completely impracticable (or maybe even unavailable), and redrawing
>> the screen is too expensive to do all the time?
>
> So where does the redrawing happen? The machine youre sitting on (let's
> call it 'A') and send remote commands or retrieving text files? Or the
> redrawing must be synced on both A and
> the remote machine? If so, then why so?

Because you want to see what you are typing. Imagine you are logged into
a server on the other side of the world. You want to edit a file on that
machine (for example a configuration file for the web server). You
invoke the editor on that server. Now everything the editor wants to
display must be sent to your machine so that it can display it on your
screen, and everything you do (hit a key, move the mouse) must be sent
to the remote machine so that the editor can obey your commands.

It is extremely irritating if there is a noticable delay between action
and response, so the data must be transferred in both directions
quickly.

> How does the bandwidth implies that you must edit stuff in the console on
> A?

I'm not sure what you mean be "in the console on A". What you usually do
is invoke an SSH client on A ("ssh" on Linux, "putty" on Windows) to
connect to the server and then invoke the editor there.

> And not in a nice editor with normal fonts?
> Am i missing something or your 'A' machine cannot use graphics?

Your A machine can use graphics. The server may not be able to (it's a
server, why would anyone install a GUI on it?), and even if it could,
streaming the screen contents of a rich GUI around the world may be not
be possible for bandwidth or delay reasons.

What you could do is copy the file from the server to your computer,
edit it there and then copy it back. But that's two extra steps and it
may not even be possible in some cases (maybe you can't reach the server
directly, but only over one or more bastion hosts).

> Even on 386 computers there was graphics and keybord&mouse input. That
> is definitely what I would want for editing files. Yes I've tried line
> by line eding back in DOS times and that really sucks.

There is a wide gap between line editing and graphical editors.
Text-terminal oriented editors (like vi, emacs, nano in the Unix world
or KEdit or e4 in the MS-DOS world) are not line based. They use the
full screen, and they can often also use the mouse. They are just
restricted to a rectangular grid of characters for display purposes. Not
much of a restriction if you want to edit only text.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp at hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel



More information about the Python-list mailing list