Cutoff sentence: Define scope of generality by either supplying a key value (a GNX if you want -- I use a URL/xxx construct) for, or leaving blank, these three fields defining state. Blank means that component of state is indefinite. The most general State (that can be hosted on a server somewhere) must have a keyvalue for Space, but will have Location and Standpoint blank.
On Fri, Mar 13, 2009 at 3:13 PM, Seth Johnson <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
