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