On Tue, Dec 20, 2011 at 11:48 AM, Edward K. Ream <[email protected]> wrote: > On Tue, Dec 20, 2011 at 10:00 AM, Seth Johnson <[email protected]> > wrote: > >>> Thus, the keys are an attempt to do the wrong thing. > >> As long as nobody's changing the external files. If they aren't, the >> cooperation can be done in the database(s), with external files just >> written as the "current situation" of the database representation. > > I don't thing there is anything interesting in this direction. The > fundamental problem is keeping information in synch. By far the > simplest thing that could possibly work is to put sentinels in files. > >> Now, if people recognize the database representation as universal for >> any app, then they may readily accept that they shouldn't mess with >> the flat file. To me, no separate flat file should be needed, as all >> "files" should be universally interoperable, distributed and >> outlineable contexts. > > The "everything in one file" approach seems to me to be a mirage. It > doesn't really add anything except a lot of complexity.
For me, there don't need to be any files, just a lot of "nodes" and their attributes -- but they are all brought together particular purposes using one uniform formal schema, so all that really needs to be managed and transferred between contexts and physical servers while you're manipulating your "views," is metadata. When you break it down this way, the attribute values are hosted at multiple particular servers, from which they can be accessed as you navigate through and read a full "file" (a "context") -- but when you manipulate it, it's only the structure that's distributed, in a standard uniform metadata format. Seth > Having said that, we can imagine a "clone server", as has been > suggested, being implemented using a single sqlite file. Which might be said to be similar to what I'm talking about, except I provide for specifying contexts, states, and scopes of relevance for nodes and their attribute values. > It seems to me that the real problem is to make sense out of BH's > (LeoUser's) old old suggestion to create a "sea of nodes". This > raises many other issues. For example, does a node include its child > links? (Imo, it probably should not include parent links, as those > links would depend on context). In my architecture, nodes point up to their parents. You access all the nodes for a context, and they come with pointers to their parents, and maybe the server can traverse that and give them to you in outline order, or you can do that locally once the server just provides the relevant nodes. > At present, I don't see a good way forward. That's ok: I've got bugs to fix > ;-) :-) Seth > 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. > -- 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.
