_ RU.OS.CMP (2:5077/15.22) _________________________________________ RU.OS.CMP _
From : Anthony Solovjoff 2:5030/168 31 Oct 98 22:58:06
Subj : Итоги обсуждения пpотокола для теpминалов
________________________________________________________________________________
Hi Julius!
29 Oct 98, Julius Goryavsky writes to All & Anthony Solovjoff:
JG> * Forwarded from area 'RU.OS.CMP'
JG> Антон, видимо ты пpопустил начало дискуссии, поэтому
JG> повтоpю основные тезисы, а заодно подведу итоги данного
JG> обсуждения.
JG> Итак я пpедлагаю вместо использования ANSI, VT и тому
JG> подобных escape-последовательностей pассматpивать дpайвеp
JG> теpминала как подсистему, котоpая умеет выполнять команды
JG> следующего фоpмата:
Ага, понятно. Я предпочитаю думать об этой конструкции прилагательно к Unix,
ибо: 1. мне его легче представлять, 2. то, что ты предлагаешь должно вписываться
в частности туда, 3. в Unix'е культура работы с терминалами достаточно
продвинута и будет с чем сравнивать. Во-вторых, я предпочитаю думать не о
терминалах по сети, а о терминалах за последовательным портом, поскольку
деятельность через сеть поддержать проще.
Hачнем с того, нам необходимо поддержать программы, которые пишут/читают
терминал как файл. Значит, драйвер терминала обязан будет предложить устройство,
на которое можно писать как на tty. Кроме того, надо иметь возможность куда-то
слать вызовы твоего протокола. Итого наберем либо пару устройств - /dev/ttyJG,
/dev/ttyJGx, либо одно устройство с набором ioctl'ей для управления терминалом.
Всякий такой терминал находится за последовательным портом, потому я должен буду
об'яснить драйверу /dev/ttyJG, что на самом деле надо работать в определенный
последовательный порт. Добиться от производителей терминалов единообразия
вряд-ли удастся, потому наверняка драйверов /dev/ttyJG у меня окажется столько
же, сколько типов терминалов. При переключении терминала из порта в порт
придется об'яснять драйверу /dev/ttyJG что последовательный порт сменился.
Далее, curses должна будет знать какой интерфейс поддерживает данный конкретный
/dev/ttyJG, например драйвер терминала от IBM может пользоваться ioctl'ями а от
HP записью на отдельное устройство /dev/ttyJGx. curses будет содержать и тот и
другой код, должна будет уметь выбирать нужный, да еще curses может быть и
модифицировать придется под какие-то терминалы :)
Самое интересное наступает когда мы начинаем пытаться использовать традиционные
прелести терминалов. Предположим, я вытащил терминал и воткнул модем - плохо,
ему в этот порт уже AT не скажешь. Или вот до сих пор я мог спокойно менять
терминал на принтер, теперь - фиг. Или я мог гонять zmodem, ppp, uucp, ftn, а
теперь? Или я мог позвонить на access server модемом, пройти через PAD, telnet и
работать, притом полученный последовательный канал был непрозрачен и семибитен,
а теперь? Можно устать приводить примеры того, какие работающие конструкции
перестали бы работать, если бы терминалы были такими, как ты предлагаешь.
А вот сделать такую игрушечку по сети - небольшая модификация curses, демон,
который будет заниматься открытием сессий и подсовыванием pty и
программка-клиент - это пожалуйста, кто бы возражал, только зачем? Думаю, спроса
не будет.
И, кстати, ты зря обижаешься на esc-терминалы. При приложении рук они
_действительно_ _работают_ _хорошо_. Если бы у меня хоть раз хоть в одной
программе на терминале пользователя испортилась картинка, я бы немедленно от
стыда повесился :)
\\ 0<
(A)
|
--- GoldED 2.51.A1026 UNREG * Origin: The Clockwork Mailman, 7(812)174-1763, 00:00-19:00 (2:5030/168)
