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

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Mon Feb 07 2000 - 16:52:24 PST


From: Eric Armstrong <eric.armstrong@eng.sun.com>

Jeff Miller wrote:
>
> From: Jeff Miller <jeffm@dynamite.com.au>
>
> On Mon, Feb 07, 2000 at 02:18:58PM -0800, Eric Armstrong wrote:
> > > Maybe he was. Maybe he's an RMS who never found his ESR.
> > >
> > Now you got me. What's an RMS? What's an ESR?
>
> I don't know wether your serious or joking. so...
>
> Richard Stallings (www.gnu.org) and
> Eric S Raymond (http://www.tuxedo.org/~esr/)
>
Thanks. I never joke about my ignorance.
If I did, I'd die laughing...

> Could someone provide a sketch on the modules/units we'd need...
>
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:
  Functional Requirements --> Functional Specification
    --> Design Requirements --> Design Specification

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?

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

Don’t buy your Valentine a Gift by clicking here.
<a href=" http://clickme.onelist.com/ad/SparksValentine11 ">Click Here</a>

------------------------------------------------------------------------

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 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT