Thanks. I never joke about my ignorance.

If I did, I'd die laughing...

I think it's still a *bit* premature for that, but not by much. I've been doing some napkin design work, too, mostly as questions sent out to this forum. But we need to be really clear on the functional goals of the system (both initial and future) in order to steer the design discussions.

Since giving the presentation last Thursday, I've been giving more thought to what the "core" of the system should be. The key to open source is to hack a nucleus that can be used right away. After that, the system can grow by leaps and bounds.

We are thinking in terms of integrating email, Web documents, Augment, and source code.

Of those, I would put source code last. It's an interesting use of the system, but the problems are less fundamental to making everything work together.

An Augment front end looks like a possible starting place, but mostly because it will give us something to look at and give us a detailed set of requirements for capabilities the system really needs to have. (I mean, at a *minimum* it should do what Augment is already capable of, shouldn't it?)

As interesting as that starting point is, though, I don't see that it attacks the really fundamental problem. That problem, as I see it, is "How do you integrate email and hyperdocuments?

The one part of that which seems clear to me is that we should be able to eliminate the current separation between my email folders and my file folders. It should be possible to mail a hierarchical document, receive responses to sections of it, traverse as-yet-unread responses, create a new version, and mail that.

That's one possibility. Or maybe we want something that supports "collaborative authoring" in an even more direct fashion. Such a system might use a two-tier system of email messages and documents. Or maybe the document needs to exist in a central server...

The major question to answer is: What functions do we need? If we can visualize the system we need, and "see" it in operation in our mind's eye, then the design requirements become clear.

I guess what I'm saying is:

So: What do we need? How will an interactive email-like capability co-exist with a document system in the most meaningful way?

We have XML. That gives us hierarchy and linking. We have email clients. Maybe we could utilize such a client to package up a document or a set of replies and send them off. How then do we shuttle a received message to the DKR? Do we have to save it as a file and then read it in? Or is there a better mechanism for doing that? (Can redirect an incoming file to a process, for example? Or can we redirect it to a folder and have the DKR process check for new files periodically?)

At what point does differencing occur, and what is the best way to manage responses to nodes that have been deleted or moved? Should the ID of every node contain the original path at which it was created? (If a node did not exist at it's original location, a search of all nodes would then find it.) Or should a "phantom" node always exist that points to the current location of the node when it has moved. (Dually linked, so that whenever the node changes positions, the phantom's pointer can be updated.)

Of course, now *I'm* going off into the design weeds again. It's so hard to stay focused on the real point -- what is that we want the system to DO?

Sincerely,

Eric Armstrong
eric.armstrong@eng.sun.com