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.
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).
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.
* All references from Node->Node are between versioned Node objects.
* 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.
I can update the IDL to reflect this discussion. I'll try to put it
on the ZWiki and send a ref.
>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
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:58 PDT