We are considering within the document only I think. How are links
between documents handled?
* Lee Iverson <leei@ai.sri.com> [010105 11:34]:
> In message <Pine.LNX.4.30.0101041112140.896-100000@jack.pacbell.net>, Eugene Er
> ic Kim writes:
> >On Thu, 4 Jan 2001, Lee Iverson wrote:
> >
> >> >Questions:
> >> > Why does an ElementNode have a child?
> >> > Why is it a Node object, rather than a Path object?
> >> > A node that existed here would not have any existence
> >> > in the Path structure, would it? Doesn't that make
> >> > impossible to reuse substructure?
> >>
> >> This is partly explained above. A key observation for reusing
> >> structure is that any particular Node may be inserted into position
> >> using any EditablePath object, irrespective of which Document the Path
> >> is in or how many other Paths exist which contain that Node.
> >
> >I had the same question, and am still not clear. You have a tree of
> >paths, each of which points to nodes or potentially trees of nodes. If
> >you're placing a node that has a subtree of nodes into a new path, then
> >you've reused substructure, so I understand that point. My question is,
> >when do you create a child node versus a child path?
>
> Two rules here:
> 1) All version information is held by Node objects and the basic means
> of modifying a node involves a clone-new-version/modify sequence.
This is what you described below in your desciption, this makes sense.
> 2) All Node modifications happen in a context defined by an
> EditableNode. Thus, all Node modifications happen via Paths
> (i.e. with respect to a particular document).
interface GroupingNode {
};
interface Document : GroupingNode {
...
Assuming the above, are all Path objects children of GroupingNodes?
> Let's say I want to add an existing Node (newChild) as
> the child of some other Node (node1) which I have a Path (path1)
> to. Let's watch the operation:
> 1) Obtain Path (path2) to Node before/after insertion point.
> 2) Obtain EditablePath (epath2) with edit() method on Path.
> 3) Invoke insertBefore()/insertAfter() on epath2 with Node newChild.
> 3.1) System creates new version of node1 (newNode1) and links to
> previous version.
> 3.2) System inserts newChild at correct place in newNode1's array of
> children.
> 3.3) System updates path1 to reflect newer version of node1.
>
> A couple of more points that fall out of this:
> * There are actually two distinct kinds of references to a Node: a
> versioned reference (i.e. to a particular Node object in the pool),
> and a current reference (i.e. to the most up-to-date version of a
> Node). This can easily be implemented by having a fixed object
> of type CurrentNode which acts as a proxy for the Node object and is
> updated whenever a newer version is created.
I don't understand what you mean by fixed object. Can you use a version
attribute of the Node class? This would cause other ramifications.
> * All references from Node->Node are between versioned Node objects.
Does this limit us? As long as we are within a GroupingNode this should
be fine.
> * If we then assume that we have both versioned and current Path
> objects as well, then we should only be able to extract an
> EditablePath from a CurrentPath object.
>
> >Some general questions: Are there situations when you want nodes to know
> >their parents? Suppose a group of people are collaborating on some
> >documents, and several people have documents pointing to a common set of
> >nodes. It would be nice if you could inform the document owners whenever
> >changes were made to those nodes.
>
> And this is actually the only difficult design issue that needs to be
> resolved given this architecture: when a Node is updated, do all
> documents which reference that Node automatically get updated as well?
> Perhaps the cleanest option is to put that question directly back on
> the user: reuse of a Node in a Document represents a commitment to the
> most recent version of that Node. Thus all CurrentPaths reference
> CurrentNodes. If I want to reuse a *particular* version of a Node,
> then I should clone the Node, creating a new CurrentNode which is
> flagged as being a copy of the versioned Node, and then make updates
> wrt. the CurrentNode.
>
> Brings up a nomenclature issue: should the default interface names be
> Node/CurrentNode or NodeVersion/Node? I'm starting to think
> NodeVersion/Node since most user interfaces will be primarily
> concerned with current Nodes.
By interface names you mean the Document or GroupNode URL references?
> I can update the IDL to reflect this discussion. I'll try to put it
> on the ZWiki and send a ref.
I tracked on paper what I think is the present version of the IDL, but a
reference would be helpful.
I used an interesting way of versioning it as I wrote it. Bootstrapping!
> >Also, what about versioning of paths? Suppose I modify a document at
> >2pm by creating a new path that points to an existing node that was last
> >updated at 1pm. If I want to view the document as it looked at 1pm, won't
> >I see this node that was added at 2pm?
>
> You can get a previous version of the document via the rootDated()
> method of the Document.
>
> -------------------------------------------------------------------------------
> Lee Iverson SRI International
> leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
> http://www.ai.sri.com/~leei/ (650) 859-3307
>
I took a quick look at the code for Xanadu. While I am not expert, it
seems obscure to me.
-- -- Grant Bowman grant@suse.com -- SuSE +1-510-628-3380 x5027 -- 580 Second Street, Suite 210 fax +1-510-628-3381 -- Oakland, CA 94607 http://www.suse.com
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:59 PDT