On Thu, Dec 22, 2011 at 3:30 PM, Kent Tenney <[email protected]> wrote: > On Thu, Dec 22, 2011 at 1:16 PM, Seth Johnson <[email protected]> > wrote: >> Okay, I think I have a sense of where you're situated. What do those >> 5 key components of the address represent? > > They are a set of child indexes > 0-5-0-0-1 > > root > \ > 0 > 1 > 2 > 3 > 4 > 5 > \ > 0 my address is 0-5-0 > \ > 0 > \ > 0 > 1 my address is 0-5-0-0-1 > > make sense? > > The Leo file can be reconstructed from these addresses: > address 0 is the first root node > address 1 is the second root node > address 0-4 is the fifth child of the first root node > etc.
Got it. And I gather that with p.key(), this is a Leo feature, where these chains of child indexes are stored with each node. It wouldn't be particularly hard to add a Parent attribute, holding the gnx of the Parent -- but why you would bother, just to solve your problem, is what you would wonder; and I don't understand everything that's handled with these chain addresses. This probably relates to the earlier question of how external files relate to the db backend. And I imagine that's caught up in how Leo does that, perhaps using these address chains. I would guess they would help track what changes have occurred between versions -- in particular, among external files in a collaborative context. Just guessing there. Whereas my concept is about stuff only going on in the database, and if need be updating external files with the current status of the database representation. My approach is about generalizing how to map data/content to URLs (or, a standard *set* of URL types defining a standardized, generalized notion of a context) for data that's cloned, distributed and manipulated in shared outlines. I store tree structure in a minimal, flat way rather than store arbitrarily complex structures, and then let tree traversal be done programmatically. However, assuming that backend, one can certainly add attributes like "address" holding chain addresses like you use, if those kinds of addresses are the optimal way to do whatever you're using them for. Not that that would necessarily be of interest to you in solving your problem. When I say address, I'm not saying "where in the tree," but something more like "exactly how a node or data is being used," so the backend server can manage the data, keeping it "in scope". That's the kind of "clone server" it is. 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.
