On Fri, Mar 13, 2009 at 11:54 AM, Edward K. Ream <[email protected]> wrote: > > > > On Mar 13, 10:13 am, "Edward K. Ream" <[email protected]> wrote: > >> > #...@leo-db:unique-id-and-timestamp >> >> > Could this be eliminated? >> >> Maybe. > > I think 'maybe' can be changed to 'almost certainly'. Given a capable- > enough db, we can reliably associate entries in that db with files > using file modification dates and checksums. > > However, I would prefer to use the "sentinel" above as a shorthand for > such a connection. > > As a boundary case, the db could contain the entire outline > corresponding to the "derived" file. In other words, all the > representation questions become details :-) > > In this sense, the db contains all the shadow files, with the > additional advantage of a secure connection between public and private > files. > > Not everything is truly "solved", however, even in this world of > magic. For instance, given an external file (and it's #...@leo-db > sentinel) we can determine all the clones in the .leo file that exist > in the external file. However, there is still a question of cross- > version clones. That is, a "snapshot" of the external file (in the > leo-db) allows us link clones from the .leo file to the external file, > and vice versa, but *only within the version of the db corresponding > to the @leo-db sentinel*. > > I suppose we can assume the existence of more magic, that preserves > clone links across different versions of the leo-db...
Whenever we start having fun, clones come along and spoil it. Lets pretend: - clones become equivalent to symlinks, with a target node, link nodes. Pro: - easier to explain "clones are like symlinks" - possible to fully emulate Leo's content management via filesystem (increasing feasibility of text based Leo) - break the logjam between Leo and ... (seems like many discussions of exciting potential (including db backing) end with "no can do because of clones" - simplify Leo's code base? Cons: - eliminate the elegance of all clones being equivalent - ... ? > > The point is this: the "magic" leo-db will, in some sense, be the > union of all differing views of all the external files. That is, the > union of all the differing *private, per-user* views of the .leo > file. For example, in the present development scheme, each Leo > developer has a private view (leoPy.leo) of the shared public view > (leoPyRef.leo). So leo-db is the union of all leoPy.leo files, not > just the union of all leoPyRef.leo files. It's quite a project... > > Edward > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
