Here's how I think about distributed outlining (with clones): Come up with a concept of State being "scope of generality." Specify scope of generality with 3 notions: 1) Space, which may contain multiple physical 2) Locations, which in turn may host multiple 3) Standpoints. Define scope of generality by either supplying a key value (a GNX if you want -- I use a URL/xxx construct)
Conceptualize outlines as an expanded concept of a database relation. Rather than two simple entities related, define a relation as between a particular Use of a more general Use Type, related to multple particular Links of a more general Link Type. Call these relations "Contexts." Then any changes to any attribute of a Use (topmost node) or a Link (children nodes), can be updated or refreshed individually from an "authoritative host" that's defined by the State and Context: *State:* Space / Location / Standpoint *Context:* Use Type / Use / Link Type ( / Links) I present this because it's my notion of a most general model for distributed outlining. Cloning isn't just cloning of a node -- it's an outcome of distributed maintenance of state at the attribute level. Seth On Fri, Mar 13, 2009 at 2:44 PM, Kent Tenney <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
