Re: [unrev-II] DKR for Open Source: Core

From: Jeff Miller (
Date: Mon Feb 07 2000 - 18:23:13 PST

From: Jeff Miller <>

On Mon, Feb 07, 2000 at 04:52:24PM -0800, Eric Armstrong wrote:
> 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.

That's what's so good about sketchs. No-one minds if you change them every
five minutes.
> 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.

Perhaps, an inital convention on the file format and a tool for "map

> 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...

I sort of know what your getting at. The trouble is that we've always
viewed corespondence as a seperate thing to authoring. letters vs books.
Want to talk paradigm shifts this is one of them. We going to have change
the way these things behaive.

As a short term method if we could parse email in some form and the store
that parsed and interlink form. very vage I know.

Just take a look at this email as an example. most of it is your original
text. If the parser understood this was quoted from your email then the
post parsed form could be interlink (forward and backward) with your
original email. This would allow viewing of comment recieved on individual
paragraphs to be listed as part of you original email or for your email to
be inserted in to this one to present something similar to what you see
> 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.

This is the second hardest task. The hardest is conveying this image to
other people.

> 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?)

This holds promise. create a local deliver agent, a replacement for

> 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?

Solve all our problems :).


--------------------------- ONElist Sponsor ----------------------------

Valentine's Day Shopping Made Simple.
<a href=" ">Click Here</a>


Community email addresses:
  Post message:
  List owner:

Shortcut URL to this page:

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT