<! date> Date: Wed, 18 Oct 2000 17:04:13 -0700
Thanks for the encouragement. [in your letter yesterday
The architecture I've been working [reported in my letter yesterday] on hit a big snag in the last couple of days. The issue revolves around the difference between links that are included as part of a node's text content, and pointers to contained substructures that are included in a node's sublist.
The problem has had me flumoxed enough that I began writing this message to describe the problem. In the process, I've come up with at least one technical solution, but it implies the need for two different ways of creating links that will be very similar, but subtly different. So even if the implementation makes sense, will the functional behavior be reasonable??
The fundamental design consists of nodes and lists. Lists contain nodes, and nodes have one or more lists. So far, so good.
A node can even have multiple parents, by replacing the usual "parent pointer" with a list that points to all of its parents. When moving or removing a node, the move always occurs in some viewing context, defined by the list that the user is currently displaying. Still, we're good.
The system also distinguishes between the "content" subtree and the "structure" subtree, which helps to limit the kind of operations that make sense in each area.
All is ok so far. But then we get to the concept of links. Links that point to other nodes are fine. But the kind of link that says "include link content here" does not make sense in the "content" portion of a node. It's like saying, "include that email thread right *here*" -- that is, to include that hierarchical collection of emails, right in the middle of this paragraph.
No, in a one-node-per-paragraph system, that doesn't make much sense. It would make all kinds of sense to include that thread *underneath*, the current paragraph. But none at all to include it *inside* the current paragraph.
So the conceptual snag is this:
Since the behaviors are so similar, they cry out for a common heritage in the class hierarchy. But since their positions in the hierarchy are so different, they require separate treatment.
Some possiblities for resolving the dilemma include:
(unfortunately, there is no good way to force the constructors to specify those values, and we need to avoid set() methods to force versioning -- or we could add set() methods and declare by fiat that view control changes and link type changes are not versioned -- TBD)
..in ContainedNode, changes current versionID and reports change to parents
..if policy says to expand, and calling node is an instance of Nodelink, show link instead