michael@0: michael@0: # The Design of GCLI michael@0: michael@0: ## Design Goals michael@0: michael@0: GCLI should be: michael@0: michael@0: - primarily for technical users. michael@0: - as fast as a traditional CLI. It should be possible to put your head down, michael@0: and look at the keyboard and use GCLI 'blind' at full speed without making michael@0: mistakes. michael@0: - principled about the way it encourages people to build commands. There is michael@0: benefit from unifying the underlying concepts. michael@0: - automatically helpful. michael@0: michael@0: GCLI should not attempt to: michael@0: michael@0: - convert existing GUI users to a CLI. michael@0: - use natural language input. The closest we should get to natural language is michael@0: thinking of commands as ```verb noun --adjective```. michael@0: - gain a touch based interface. Whilst it's possible (even probable) that touch michael@0: can provide further benefits to command line users, that can wait while we michael@0: catch up with 1985. michael@0: - slavishly follow the syntax of existing commands, predictability is more michael@0: important. michael@0: - be a programming language. Shell scripts are mini programming languages but michael@0: we have JavaScript sat just next door. It's better to integrate than compete. michael@0: michael@0: michael@0: ## Design Challenges michael@0: michael@0: What has changed since 1970 that might cause us to make changes to the design michael@0: of the command line? michael@0: michael@0: michael@0: ### Connection limitations michael@0: michael@0: Unix pre-dates the Internet and treats almost everything as a file. Since the michael@0: Internet it could be more useful to use URIs as ways to identify sources of data. michael@0: michael@0: michael@0: ### Memory limitations michael@0: michael@0: Modern computers have something like 6 orders of magnitude more memory than the michael@0: PDP-7 on which Unix was developed. Innovations like stdin/stdout and pipes are michael@0: ways to connect systems without long-term storage of the results. The ability michael@0: to store results for some time (potentially in more than one format) michael@0: significantly reduces the need for these concepts. We should make the results michael@0: of past commands addressable for re-use at a later time. michael@0: michael@0: There are a number of possible policies for eviction of items from the history. michael@0: We should investigate options other than a simple stack. michael@0: michael@0: michael@0: ### Multi-tasking limitations michael@0: michael@0: Multi-tasking was a problem in 1970; the problem was getting a computer to do michael@0: many jobs on 1 core. Today the problem is getting a computer to do one job on michael@0: many cores. However we're stuck with this legacy in 2 ways. Firstly that the michael@0: default is to force everything to wait until the previous job is finished, but michael@0: more importantly that output from parallel jobs frequently collides michael@0: michael@0: $ find / -ctime 5d -print & michael@0: $ find / -uid 0 -print & michael@0: // good luck working out what came from where michael@0: michael@0: $ tail -f logfile.txt & michael@0: $ vi main.c michael@0: // have a nice time editing that file michael@0: michael@0: GCLI should allow commands to be asynchronous and will provide UI elements to michael@0: inform the user of job completion. It will also keep asynchronous command michael@0: output contained within it's own display area. michael@0: michael@0: michael@0: ### Output limitations michael@0: michael@0: The PDP-7 had a teletype. There is something like 4 orders of magnitude more michael@0: information that can be displayed on a modern display than a 80x24 character michael@0: based console. We can use this flexibility to provide better help to the user michael@0: in entering their command. michael@0: michael@0: The additional display richness can also allow interaction with result output. michael@0: Command output can include links to follow-up commands, and even ask for michael@0: additional input. (e.g. "your search returned zero results do you want to try michael@0: again with a different search string") michael@0: michael@0: There is no reason why output must be static. For example, it could be michael@0: informative to see the results of an "ls" command alter given changes made by michael@0: subsequent commands. (It should be noted that there are times when historical michael@0: information is important too) michael@0: michael@0: michael@0: ### Integration limitations michael@0: michael@0: In 1970, command execution meant retrieving a program from storage, and running michael@0: it. This required minimal interaction between the command line processor and michael@0: the program being run, and was good for resource constrained systems. michael@0: This lack of interaction resulted in the processing of command line arguments michael@0: being done everywhere, when the task was better suited to command line. michael@0: We should provide metadata about the commands being run, to allow the command michael@0: line to process, interpret and provide help on the input.