The Tor Browser / file comparison
comparison: toolkit/devtools/gcli/source/docs/design.md
toolkit/devtools/gcli/source/docs/design.md
- changeset 0
- 6474c204b198
equal
deleted
inserted
replaced
| -1:000000000000 | 0:25f3cd643f84 |
|---|---|
| 1 | |
| 2 # The Design of GCLI | |
| 3 | |
| 4 ## Design Goals | |
| 5 | |
| 6 GCLI should be: | |
| 7 | |
| 8 - primarily for technical users. | |
| 9 - as fast as a traditional CLI. It should be possible to put your head down, | |
| 10 and look at the keyboard and use GCLI 'blind' at full speed without making | |
| 11 mistakes. | |
| 12 - principled about the way it encourages people to build commands. There is | |
| 13 benefit from unifying the underlying concepts. | |
| 14 - automatically helpful. | |
| 15 | |
| 16 GCLI should not attempt to: | |
| 17 | |
| 18 - convert existing GUI users to a CLI. | |
| 19 - use natural language input. The closest we should get to natural language is | |
| 20 thinking of commands as ```verb noun --adjective```. | |
| 21 - gain a touch based interface. Whilst it's possible (even probable) that touch | |
| 22 can provide further benefits to command line users, that can wait while we | |
| 23 catch up with 1985. | |
| 24 - slavishly follow the syntax of existing commands, predictability is more | |
| 25 important. | |
| 26 - be a programming language. Shell scripts are mini programming languages but | |
| 27 we have JavaScript sat just next door. It's better to integrate than compete. | |
| 28 | |
| 29 | |
| 30 ## Design Challenges | |
| 31 | |
| 32 What has changed since 1970 that might cause us to make changes to the design | |
| 33 of the command line? | |
| 34 | |
| 35 | |
| 36 ### Connection limitations | |
| 37 | |
| 38 Unix pre-dates the Internet and treats almost everything as a file. Since the | |
| 39 Internet it could be more useful to use URIs as ways to identify sources of data. | |
| 40 | |
| 41 | |
| 42 ### Memory limitations | |
| 43 | |
| 44 Modern computers have something like 6 orders of magnitude more memory than the | |
| 45 PDP-7 on which Unix was developed. Innovations like stdin/stdout and pipes are | |
| 46 ways to connect systems without long-term storage of the results. The ability | |
| 47 to store results for some time (potentially in more than one format) | |
| 48 significantly reduces the need for these concepts. We should make the results | |
| 49 of past commands addressable for re-use at a later time. | |
| 50 | |
| 51 There are a number of possible policies for eviction of items from the history. | |
| 52 We should investigate options other than a simple stack. | |
| 53 | |
| 54 | |
| 55 ### Multi-tasking limitations | |
| 56 | |
| 57 Multi-tasking was a problem in 1970; the problem was getting a computer to do | |
| 58 many jobs on 1 core. Today the problem is getting a computer to do one job on | |
| 59 many cores. However we're stuck with this legacy in 2 ways. Firstly that the | |
| 60 default is to force everything to wait until the previous job is finished, but | |
| 61 more importantly that output from parallel jobs frequently collides | |
| 62 | |
| 63 $ find / -ctime 5d -print & | |
| 64 $ find / -uid 0 -print & | |
| 65 // good luck working out what came from where | |
| 66 | |
| 67 $ tail -f logfile.txt & | |
| 68 $ vi main.c | |
| 69 // have a nice time editing that file | |
| 70 | |
| 71 GCLI should allow commands to be asynchronous and will provide UI elements to | |
| 72 inform the user of job completion. It will also keep asynchronous command | |
| 73 output contained within it's own display area. | |
| 74 | |
| 75 | |
| 76 ### Output limitations | |
| 77 | |
| 78 The PDP-7 had a teletype. There is something like 4 orders of magnitude more | |
| 79 information that can be displayed on a modern display than a 80x24 character | |
| 80 based console. We can use this flexibility to provide better help to the user | |
| 81 in entering their command. | |
| 82 | |
| 83 The additional display richness can also allow interaction with result output. | |
| 84 Command output can include links to follow-up commands, and even ask for | |
| 85 additional input. (e.g. "your search returned zero results do you want to try | |
| 86 again with a different search string") | |
| 87 | |
| 88 There is no reason why output must be static. For example, it could be | |
| 89 informative to see the results of an "ls" command alter given changes made by | |
| 90 subsequent commands. (It should be noted that there are times when historical | |
| 91 information is important too) | |
| 92 | |
| 93 | |
| 94 ### Integration limitations | |
| 95 | |
| 96 In 1970, command execution meant retrieving a program from storage, and running | |
| 97 it. This required minimal interaction between the command line processor and | |
| 98 the program being run, and was good for resource constrained systems. | |
| 99 This lack of interaction resulted in the processing of command line arguments | |
| 100 being done everywhere, when the task was better suited to command line. | |
| 101 We should provide metadata about the commands being run, to allow the command | |
| 102 line to process, interpret and provide help on the input. |
