[288] in Athena_Backup_System
Revision to Crippled Mode spec -- UI section.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Fri Jul 12 18:03:03 1996
Date: Fri, 12 Jul 1996 18:02:52 -0400 (EDT)
From: Bill Cattey <wdc@MIT.EDU>
To: athena-backup@MIT.EDU
From our discussions about how the UI for crippled mode has to be (IE a
separate process), I changed the Crippled Mode figure (#2) to have
a separate UI process just like normal mode, and I made the following
change to the User Interface section of the Crippled Mode Spec:
121,124c121,151
< The user interface will be integral to the Crippled
< Mode Master. When the Crippled Mode Master is started,
< the operator will be presented with a shell-like
< interface.
---
> For convenient operation, the user interface will appear
> to be integral to the Crippled Mode Master. In fact,
> the Crippled Mode Master will have a separate User
> Interface Client process which will talk to the
> Crippled Mode Master through RPC calls. Otherwise it
> would be required that the Crippled Mode master be
> multi-threaded in order to utilize an RPC reader loop,
> and to do keyboard I/O. For simplicity's sake, neither
> the Crippled Mode Master, nor the normal mode Master are
> multi-threaded.
>
> The Crippled Mode User Interface presents a command prompt,
> listens for the few supported Crippled Mode commands, and
> prompts for additional information as required. There are
> no plans to produce a fancy GUI Crippled Mode
> user interface client.
>
> The normal mode User Interface Client cannot be used in
> Crippled Mode because it has a fundamentally different
> work flow. The normal mode User Interface Client assumes
> the Master will extract from the database all the
> information needed to fully specify operations. The
> Crippled Mode User Interface Client, in contrast will
> have to prompt for, and listen for required specifications.
>
> For example: in performing a Crippled Mode dump, the
> operator is prompted to specify which Media Slave is
> to be used, the filesystem type (and if the type is AFS
> whether the dump is to be from read/write or clone volumes).
> All this information would ordinarily be extracted from
> the database without bothering the operator.
