toolkit/devtools/gcli/source/docs/design.md@129ffea94266
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.
2 # The Design of GCLI
4 ## Design Goals
6 GCLI should be:
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.
16 GCLI should not attempt to:
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.
30 ## Design Challenges
32 What has changed since 1970 that might cause us to make changes to the design
33 of the command line?
36 ### Connection limitations
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.
42 ### Memory limitations
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.
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.
55 ### Multi-tasking limitations
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
63 $ find / -ctime 5d -print &
64 $ find / -uid 0 -print &
65 // good luck working out what came from where
67 $ tail -f logfile.txt &
68 $ vi main.c
69 // have a nice time editing that file
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.
76 ### Output limitations
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.
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")
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)
94 ### Integration limitations
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.
