1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/toolkit/devtools/gcli/source/docs/design.md Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,102 @@
1.4 +
1.5 +# The Design of GCLI
1.6 +
1.7 +## Design Goals
1.8 +
1.9 +GCLI should be:
1.10 +
1.11 +- primarily for technical users.
1.12 +- as fast as a traditional CLI. It should be possible to put your head down,
1.13 + and look at the keyboard and use GCLI 'blind' at full speed without making
1.14 + mistakes.
1.15 +- principled about the way it encourages people to build commands. There is
1.16 + benefit from unifying the underlying concepts.
1.17 +- automatically helpful.
1.18 +
1.19 +GCLI should not attempt to:
1.20 +
1.21 +- convert existing GUI users to a CLI.
1.22 +- use natural language input. The closest we should get to natural language is
1.23 + thinking of commands as ```verb noun --adjective```.
1.24 +- gain a touch based interface. Whilst it's possible (even probable) that touch
1.25 + can provide further benefits to command line users, that can wait while we
1.26 + catch up with 1985.
1.27 +- slavishly follow the syntax of existing commands, predictability is more
1.28 + important.
1.29 +- be a programming language. Shell scripts are mini programming languages but
1.30 + we have JavaScript sat just next door. It's better to integrate than compete.
1.31 +
1.32 +
1.33 +## Design Challenges
1.34 +
1.35 +What has changed since 1970 that might cause us to make changes to the design
1.36 +of the command line?
1.37 +
1.38 +
1.39 +### Connection limitations
1.40 +
1.41 +Unix pre-dates the Internet and treats almost everything as a file. Since the
1.42 +Internet it could be more useful to use URIs as ways to identify sources of data.
1.43 +
1.44 +
1.45 +### Memory limitations
1.46 +
1.47 +Modern computers have something like 6 orders of magnitude more memory than the
1.48 +PDP-7 on which Unix was developed. Innovations like stdin/stdout and pipes are
1.49 +ways to connect systems without long-term storage of the results. The ability
1.50 +to store results for some time (potentially in more than one format)
1.51 +significantly reduces the need for these concepts. We should make the results
1.52 +of past commands addressable for re-use at a later time.
1.53 +
1.54 +There are a number of possible policies for eviction of items from the history.
1.55 +We should investigate options other than a simple stack.
1.56 +
1.57 +
1.58 +### Multi-tasking limitations
1.59 +
1.60 +Multi-tasking was a problem in 1970; the problem was getting a computer to do
1.61 +many jobs on 1 core. Today the problem is getting a computer to do one job on
1.62 +many cores. However we're stuck with this legacy in 2 ways. Firstly that the
1.63 +default is to force everything to wait until the previous job is finished, but
1.64 +more importantly that output from parallel jobs frequently collides
1.65 +
1.66 + $ find / -ctime 5d -print &
1.67 + $ find / -uid 0 -print &
1.68 + // good luck working out what came from where
1.69 +
1.70 + $ tail -f logfile.txt &
1.71 + $ vi main.c
1.72 + // have a nice time editing that file
1.73 +
1.74 +GCLI should allow commands to be asynchronous and will provide UI elements to
1.75 +inform the user of job completion. It will also keep asynchronous command
1.76 +output contained within it's own display area.
1.77 +
1.78 +
1.79 +### Output limitations
1.80 +
1.81 +The PDP-7 had a teletype. There is something like 4 orders of magnitude more
1.82 +information that can be displayed on a modern display than a 80x24 character
1.83 +based console. We can use this flexibility to provide better help to the user
1.84 +in entering their command.
1.85 +
1.86 +The additional display richness can also allow interaction with result output.
1.87 +Command output can include links to follow-up commands, and even ask for
1.88 +additional input. (e.g. "your search returned zero results do you want to try
1.89 +again with a different search string")
1.90 +
1.91 +There is no reason why output must be static. For example, it could be
1.92 +informative to see the results of an "ls" command alter given changes made by
1.93 +subsequent commands. (It should be noted that there are times when historical
1.94 +information is important too)
1.95 +
1.96 +
1.97 +### Integration limitations
1.98 +
1.99 +In 1970, command execution meant retrieving a program from storage, and running
1.100 +it. This required minimal interaction between the command line processor and
1.101 +the program being run, and was good for resource constrained systems.
1.102 +This lack of interaction resulted in the processing of command line arguments
1.103 +being done everywhere, when the task was better suited to command line.
1.104 +We should provide metadata about the commands being run, to allow the command
1.105 +line to process, interpret and provide help on the input.
