Remembering back to long ago when we only had 640k of RAM at the most, there were editors that kept three screens of data in memory at once - the current page, the previous page, and the next page. When the user scrolled forward (say), parts of the next page would be brought in, and when necessary another page would be read in from disk. An analogy would be a long continuous (paper) scroll, where only one part in the middle would be visible at any one time.
This scheme would seem to fit right in with your thoughts above. On Saturday, October 24, 2020 at 9:42:49 AM UTC-4, Edward K. Ream wrote: > > Issue #1123 <https://github.com/leo-editor/leo-editor/issues/1123> is > arguably the most interesting issue with the "Sabbatical" label. > > Could be of any use as a huge database, say one representing the human > genome project? Here are some new thoughts. > > *Background* > > At present, Leo represents vnodes in .leo.db files using sqlite tables. On > startup, Leo loads (creates) vnodes for all the represented vnodes. > > Loading millions of vnodes seems out of the question. There is a practical > limit to how many vnodes Leo can create. > > Similarly, drawing all vnodes with Leo's existing screen drawing code has > a practical upper limit. > > > *New strategy* > > Rather than loading (and drawing) *all* vnodes for .leo.db files on > startup, Leo might load only a subset of vnodes, called the *loaded > vnodes*. Leo's .leo.db format could easily be extended to remember loaded > vnodes. A new .leo.db file would have only one loaded node. > > Leo's all_positions and all_unique_positions generators would apply only > to loaded vnodes. Ditto for Leo's legacy search commands. > > Leo would add to the loaded vnodes set using new commands, say > *load-from-sql*, which would issue an issue an sql query and populate new > loaded vnodes. You can think of load-from-sql as an extension of Leo's > clone-find commands. Deleting nodes would affect only the loaded vnodes. > Such deletions would not affect the underlying db. Instead, another new > commands, say *delete-from-sql* and *permanently-delete-nodes* would do > that. > > *Summary* > > The ideas presented here limit the number of loaded vnodes. In effect, the > loaded vnodes become a Leonine view of the underlying db. > > It is an open question how useful such Leonine views would be. > > Leo's existing commands apply only to the loaded vnodes. New commands > would add, delete and update the underlying db using either sql queries or > selected (trees of) vnodes. > > All comments welcome. > > Edward > > P.S. The associative model of data > <https://en.wikipedia.org/wiki/Associative_model_of_data> is based on a > DAG, just as normal Leo outlines. However, at this time I see no way to > leverage that to Leo's advantage. Indeed, most people want sql queries, > which the associative model does not support. > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/360233d9-b96c-42ce-9731-8837e3b7bc4bo%40googlegroups.com.
