- priority: 5 --> 1
Currently in kelp, we print the results as we find them.
What this means is that we can have results pretty quickly, that is we don't have to wait for the end of a search to see some reults being printed.
Although this is quite efficient since a search without printing is almost irrelevant, effectively kelp as a process combines two separate processes: one process operates on the index, performing a search.
The other operated on the .kelp file, performing a print.
Conceptually these two parts could be separated.
Under unix for example, to do the printing that kelp does we could even use an app called ed. ed can print a portion of a file.
The only problem is that ed is not guaranteed to be on any platform we desire to support (e.g. Windows); it is also not guatanteed to support large files which we have committed to support fully.
Therefore we could in fact develop our own implementation of ed: simpler because it only does what we want, standard is we follow some posix interface, and above all guaranteed.
Communication could happen inter process using a named pipe.
Basically searching and printing are separate processes. We can invoke the printing per se, the searching per se, or a search and print pipe which combines the two: tells the printer how to print what is found by the search engine. The printer can therefore be a web process. No linking with libraries but with pipes.
This is part of Kelp 2.0 so for kelp 1.x we are focusing on implementing the user ability to perform commands, with an eye on kelp 2.0 when we are ready for the switch.