On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream <[email protected]> wrote:
<< SNIP >> > Summary > ======= > > Let me try to give a big picture overview of my thoughts, before the > myriad complexities arise. The challenge will be to create simplicity > everywhere. The simplicity *must* be real: it must be on the order of > "webs are outlines in disguise". All formats are (outline) contexts with state, and with data elements with scopes of relevance. > Suppose *all* (or almost all) information is contained in a **Leonine > db**. The kind of the db doesn't matter, except insofar as it > supports what is needed. I'll assume sqlite db, as required by > fossil, possibly extended. > > Suppose external files start with one or more sha1 keys, which are the > *only* sentinels in a file. For example, for .py files:: > > #@sha1: <sha1 key> > > We can think of this line as a "universal link" into a database > created by a particular program. << SNIP >> > The world has not begun to appreciate how cool sha1 keys are. Any > program or project may generate them by the millions, with no fear of > conflict. Thus, we can consider sha1 keys to **be** any kind of data > structure we like! > > Thus, the one and only (Leonine) key in each external file can > represent *all* data associated with the file, not just *any* data > associated with the file. That is, we can imagine "amalgamating" data > structures (dicts) that contain, for instance: > > - The complete outline structure of the file. > - The bzr/fossil revision info, > - The (link to) the .leo file that contains the external file, > - The file paths of the .leo file and all external files, > - The list of all people who have contributed to the file, and the > revisions that each individually has made. (Think bzr blame). > - Whatever else could possibly be useful. > > So the sha1 key in the external file refers to this amalgamating data > structure. Furthermore, the format of the amalgamating data > structures can change at will, with no fear of sha1 conflicts. Thus, > data structure formats are completely dynamic: there is no such thing > as being incompatible with old data! Just to put in your pipe -- but note my last comment at the bottom, that this is mostly for thinking things through: You can have one "Leonine" key that serves to point to your amalgamating structure, or you could have a fixed number of keys in the external file that designate the Leonine-amalgamating structure as a "context" defined in terms of a uniform/universal data structure. The above items are all types of uses of types of nodes (which I call links). Each type of use combined with a type of link can have whatever nodes (or attributes of nodes) are relevant to that context, with "context" defined as a particular instance within a relationship of a use type with a link type. So the external file can have a fixed set of sha1 keys that correlate with that definition: a key for the use type (such as a Leo file), another for link type (such as a Leo node), another for particular use (LeoPyRef.leo), plus some more similar keys to designate state (a few comments on that below). << SNIP >> > The challenges > ============ > > It's all very well to put all (or almost all) info in the Leonine db. > The challenges are: > > 1. To create amalgamating data structures that can be updated simply. > Complexity here will likely doom the project. > > 2. To coordinate *distributed* Leonine db's without rewriting fossil > or bzr or sqlite ;-) > > 3. To continue to use most, if not all, of Leo's core code without > change, except where the existing code is no longer needed. > > Point 2 seems to be the biggest challenge. Let us consider a .leo > file as a form of *personal* view into the Leonine db. EKR's view > might be analogous to leoPyRef.leo, but my view should not be > "privileged" in any way: any user should be able to access the > **published view** of any other user. A published view will be (or > comprise) an amalgamating data structure. A uniform data structure would include a general representation of state, and that can include individual "standpoints" -- yet that standpoint can contain elements that others freely include in their own contexts. The point of a standpoint is about generality (or rather, making a state particular so you can work things out); it's not about published or shared or not, which can be their own toggles independently of state. State is about generality, not publishing or shareability or collaborative modifiability. So my personal standpoint I could make accessible or editable at large, but what I'm trying to do is to muck around with it before I make its state more general -- that is, intended to be pertinent to everybody in some broader "space" or among some one or more "locations." So I just designate it as my own standpoint until I'm ready to designate what state it's designed to exist within. Naturally, any element (data/text/node) within my contexts, regardless of the generality of their state, can be placed into other contexts with different states. What you do with those elements in my own contexts, just happens within them, their states and their scopes of relevance. > I don't know fossil well enough to know how my ideas map onto fossil > constructs. I suspect, though, that some correspondence will be > possible. Otherwise, the project fails challenge 2. > > Of course, fossil is not the only possible way, but as a practical > matter challenge 2 is inviolate: I don't plan to create "yet another > git" unless the payoffs (and the human help) are huge. I haven't thought much at all about integration with revision control systems, except to state that I wish those systems would be built around a uniform/universal data structure. They would then be automatically interoperable. Given the complexities of contemplating development in that area (every store has its own architecture, so whatever existing code you might find would be tailored to those), this is probably where my ideas will be hard to work with. But maybe my ideas can help clarify or organize conceptions. Seth -- 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.
