Ideas Summary (2/3)

This is a summary of ideas from a email discussion between Dave Hudson
and myself. (Part 2/3)

This contains two major topics:

2 - Multiple Data Stream
3 - TTY Handling

[2 - Multiple Data Stream]

Multiple Data Stream Uses/Goals:
    - Use it to send signal changes, and other non "main-stream" oriented
      information through the stream. (i.e. DCD changes or whatnot)
    - To send application specific information down the server/client chain
      in the "background". For example, caller id information from a callerid
      modem which you are receiving a call for.
    - Instead of the UNIXish use of the tty to just "spit" text data
      to a user, use another data-stream as a "back channel" to send
      this "out of band data" down to the user. As a default, the user-level
      library code would just take the text and spit it to the user, and
      the effect would be the same as on UNIX. However, given a program which
      wanted to do something sane, the data is now in a discrete chunk which
      can be cleanly dealt with.
      - As a specific example. Talk requests. Instead of a talk request being
        spit right at the user and then the user having to fix the screen and
        then shell to respond to the talk request. A background program could
        look for talk requests and if one happened, it could pop up a dialog
        asking if you wanted to respond requiring only a "y" or an "n" to
        either enter the talk converstaion or to dismiss the dialog and
        return the screen to normal. For those who would find that intrusive,
        a single character could be placed in the corner of the screen to
        signal the talk request. The possibilities are limitless, and all of
        them can be done without having to modify the installed "talkd" which
        the sysadmin is running.

Multiple Data Stream Specifics:
    - The stream "backchannels" will be hidden from POSIX by the userlevel
      libraries.

[3 - TTY Handling]

Main Ideas:
    - POSIX is way over the top TTY-wise
    - Use a separate tty-server for performing tty level support, however
      don't require clients to go through it. For example, SLIP/PPP/mouse
      drivers would just talk directly to the serial port. This provides both
      the isolation and flexibility of having the tty code in another server,
      AND the speed of not having to go through another server when you don't
      need it.
      - Integrating virtual terminals into the tty server would be a big
        plus.

TTY Server Specifics:
    - Base Functionality:
      - Map control signal changes to VSTa Signals
      - Selectable input modes (caniocal/raw)
      - Special Character Processing (i.e. interrupt/kill/suspend)
    - Usage Specifics:
      - The best idea we had as far as allowing the tty server to be
        "configured" to run on specific devices is this: Just allow the
        tty server to be given namer paths over which it should create a
        tty service. (for example, "cons", or "serial") The tty server
        will register itself as "tty". By opening tty and walking down
        one will be able to see a "miror" of what is in the paths which
        the TTY server is serving. For example, given namer paths:
        serial/com/01, serial/com/02, cons/01, cons/02, if the tty server
        was started up as "ttyserv serial cons", then there would also be
        "tty:serial/com/01", "tty:serial/com/02", "tty:cons/01",
        "tty:cons/02". (or perhaps that could be "tty/serial/com/01")
        However, none of the connections would actually be OPEN. That is
        to say that the tty server would not open a connection to
        "serial/com/01" until one opened "tty:serial/com/01". In addition
        any devices which are added to the serial pathspace in the namer
        would automatically show up under the serial path in the tty server,
        because the TTY server just reads the "serial" directory when someone
        asks for a file list in "tty:serial".
      - A mechanism for adding namer paths to be mirrored by the tty server
        would be necessary also.
      - Another possible idea to replace the above idea is possibly some
        kind of "filter server" system, where there is a standard way to
        open a namer path THROUGH an existing filter server.
    - Telephony Layer
      - perhaps as part of the TTY server, or perhaps as just
        a completely separate layer. A Telephony Layer, now becoming
        common in many OSs, is a good idea. This layer allows a device
        specific driver deal with the DEVICE attached to a specific port.
        For example, a "modem/fax/voicemail" modem would be handled by
        it's own Telephony driver so it could actually accept all kinds
        of incoming calls properly.
      - We didn't spend much time talking about this. The only idea
        mentioned were basically to just "let a server do it" which could
        be done with now with no work (except to write the server).
        Perhaps there are better ideas.
    - Virtual Terminal handling
      - The logical location for such handling would likely be the TTY
        server. Since non-tty devices don't have any concept of a terminal
        to virtualize.
      - Associate a "virtual screen" with every process which has a
        controlling terminal. Acts of job control are now reduced
        to connecting that processes virtual screen with the physical
        screen of the terminal. (i.e. by sending a message to the VT server)
      - interactive apps are no longer stuck inside the screen group they
        were created in. Since the VT code will hold ALL the virtual screens
        for all processes which have screens, one can get the screen of
        any process for which he has sufficient security privileges.
      - Screen resizing can be handled at the "virtual screen layer",
        allowing resizing of the physical screen "on-the-fly" to be
        much simpler.
     
Received on Wed Aug 9 12:23:07 1995