In another thread, Terry wrote: > I've always had the impression c.db and g.db share the same infrastructure as the cache? They have various other uses in some plugins etc.
Thanks, Terry, for this. It came at the perfect time. This Engineering Notebook post will discuss coming changes to Leo's caching scheme. These changes will be modest. All comments welcome. *Background* The new fast-read scheme never uses the cache to read external files or .leo files more quickly. Indeed, the read logic takes almost exactly the same time as recreating them from the cache! The cache *will always *be used to recreate data that otherwise would be written to the <globals> element: selected position and outline ratios. Let's call these bits the *global attributes*. At present, these are written to the .leo/db/globals folder. Plugins may write to c.db. These data are written to *per-file cache folders* in .leo/db. The names of these folders are a hash followed by the name of the .leo file. *Goals* 1. Create per-file folders in .leo/db *only *if plugins write to c.db. Otherwise, only the .leo/db/globals folder will be updated (with the updated global bits). 2. [Maybe] Add a --trace-cache option. This will tell people which plugins create per-leo-file folders. Alas, there is no infrastructure to do this. At present, it looks like only the bookmarks plugin uses c.db. Only a few keys are used, so the knowledge of them could be "built in", but there is no way, in general, of associating keys with plugins. 3. [Maybe] Retire the --no-cache command-line option. The --no-cache option will no longer affect reading and writing files on startup. But this option is moot *could *be retained to suppress writes to per-file folders that arise because plugins write to c.db. 4. Make the <globals> element vestigial. Imo, it's time for Leo *never* to write to the <globals> element in .leo files. *Note*: We can assume that the .leo/db folder is *always *writable. Indeed the .leo file is (usually) in the user's home directory. It's possible to mess environment vars so the .leo folder *isn't* writable, but who would want to do that? 5. [Maybe, experimental] Add marked and expanded bits to the global attributes cached in .leo/db/globals. At present, Leo writes these data to special attributes of the <v> elements corresponding to @file nodes. Caching these data instead would reduce unnecessary git diffs. I would prefer not to write them to per-file cache folders. We'll see whether this is possible. *Summary* Leo will continue update ~/.leo/db/globals with non-essential data. It may also be possible to write more data to this folder. Per-file cache folders will be retained for use by plugins. The the <globals> element in .leo files will become vestigial. This will reduce useless git diffs. I'm not sure whether to retain the --no-cache option. It will have no effect Leo's read/write code. If retained, this option would only suppress the writing of per-file folders in the cache. I'll be working on the changes in the fast-read branch. As usual, all comments welcome. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
