> Gil Regev wrote:
>
> I googled the stuff a bit and found a dead IETF draft concerning
> GUID's and the explanation of why it died and a hint that in the
> future we won't be embedding the network card address in the GUID:
>
So it died because the solution only worked on windows machines,
and had security problems, besides? Is that an accurate summary
of what you found?
> P.S. Eric, did you check WebDAV for hints on versioning?
>
WebDAV is concerned with documents. At the document level,
versioning is less of a problem. At the level of a logical
"node", it doesn't seem like a problem. But when the logical
abstraction that is a "node" is broken down into the actual
components necessary to implmement multiple-containment
hierarchies, links, categories, and content, the concept of
"versioning" becomes a lot more problematic.
I think I've got a handle on it, but the complexity is beginning
to overwhelm me. I considered dropping back to a simpler system
where node types are determined dynamically, but that creates
a need for dynamic type-checking in some cases, to make sure
that the type of node being presented makes sense in any given
situation.
Such a system would be nice and fluid. But the runtime type
checking gets costly, and the cost of screwing it up could be
even worse. So I'm thinking that static node types makes the
most sense.
The biggest issue with static node types is that I am predefining
the core nodes in the system. I *think* that StructureNodes,
TextNodes, InlineNodes, LinkNodes, and CategoryNodes are sufficient
to form the kernel for a system that meets the functional
specifications defined in the requirements documents. [I've been
vacilating on the concept of AttributeNodes. At first I thought
they were necessary, but now I'm not so sure.]
It *may* make sense to add a layer of customizable nodes on top
of that basis, where the type is "UserNode" and the subtype is
defined by the user when the node is created. I'm not sure if
how much is gained, but it can always be added later if it turns
out to be desirable -- I think.
BTW:
I'm pretty excited about the arrival of Groove on the scene.
The ability of the system to connect and synchronize with remote
systems is a huge, open "todo" item. Groove may well provide
the foundation for that piece of the puzzle.
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/5/_/444287/_/972601303/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Thu Oct 26 2000 - 16:11:46 PDT