>> we can imagine a "clone server", as has been suggested, being implemented >> using a single sqlite file.
I look forward to seeing where this db vision leads. The idea in my mind is to still use outlines to re-arange and organize data (program code, documents, task lists) for views -- could be or internal windows in Leo, external files, or passed on to other programs. The db serves as an efficient way to store, search for and import data (often will be snippets of code and text). So ... two points 1. Sentinels and flat files are not incompatible with this vision, and their relationship with outlines does not need to change The leo outline would serve as an flexible way to use the db data, and reading a file with sentinels will re-recreate an outline, but changing the db entries due to a change in an external file should come from an explicit choice of the user (i.e., not automagical, too dangerous). Nonetheless, the db should store extra node info (name, key, date, owner) that is written to sentinels that can be stored JSON like and this can be manipulated and re-read & refreshed. 2. Working collaboration will surely have many unforeseen problems Thus a restricted one-user-only version of db storage seems a better first step My guess is that few leo users, including myself, currently make full use of attributes by using or extending unknown attributes (uA's) and this would change. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
