Date: Thu, 12 Oct 2000 20:55:19 -0700

From:	Grant Bowman
	grant@suse.com Reply-To: ohs-dev@bootstrap.org

To: ohs-dev@bootstrap.org

Subject:

Draft: My one-on-one technical session with Doug

Doug and I talked about editing this to make it more accurate. It has quite a slant of my own to it right now. I figure it's best sent than hoping to find time to edit it better.

Sincerely,

-- Grant

Grant Bowman
grant@suse.com

Doug and I compared our present visions of the OHS from scratch. Doug drew another copy of what I immediately recognized as the slides he has done for the first presentation I saw with him at VA re: SourceForge. I brought a printed copy of my N-squared diagram available on the Wiki site.

Please see...

I had not translated the N-squared back to a diagram that I took it from on the wall after one of our meetings in talking about the architecture. There are some flaws but I know where it needs updating now.

The two actually map extremely well. Several of the steps we have concentrated on are things that Doug has "assumed" in his drawing, mainly the email flow from email client to the email repository and back via SMTP. The lens onto that data is of course replicated in our designs.

We talked about Eric's concerns about local storage. I don't see this as a problem because of my guess at how the system is implemented.

My understanding was that the email component will be used as it is now but adding URLs to it as it's sent out to everyone and then in essence "subscribing" the OHS to the mail list and allowing anyone to view it. I think this is an appropriate and achievable -intermidiate- step. I don't think I have read Eric's comments closely enough to have caught the nuances, so pardon the characterization.

So regarding Eric's concerns, I have thought about what it would mean to keep a copy locally and how that may or may not integrate into the OHS.

I had conceptualized a piece of the OHS system that may translate link results to plain text with the actual links to facilitate the use of documents from people not in the OHS system. A translation from (link) to (link with resultant text) can be done on import, export or dynamically if an attempt was made to view from externally.

We talked about scope and how his design was a topology, not an implementation plan.

Implementation of the parts may be on client, server, data layer, global, etc. I am more concerned with a first step, any step, to get started. Even if it's in the wrong direction, it would be forward movement to work from. IMHO that is what open source projects are about. You do what you want and if anyone else wants to fork the code, so be it, have at it. One would hope a synergy develops solidifying your code line as the base. I think this is how Apache and others can work.

We talked about the flexibility allowed when double-clicking and many of the nuances of the current Augment system that I have been working with experimentally. The context is extremely important to the command, and so there are few simple rules in this system to characterize everything.

Three types of double-clicking are

1. Click in one window, then click in another window & execute command

2. Click, give options, click to just say go

3. Click on physical location that will be moved to the top, give viewspec, then click again in the window it should appear and also execute the command. I guess this is a complex command with two locations, a command, a viewspec, and saying go.

Lastly we talked about the evolution of the project. The re-implementation of Augment is of course not an overnight project. I think Doug's concern is that the knowledge of Augment and previous projects will not be retained and built apon due to the complexity. Perhaps re-implementing a compiler to compile the actual Augment code may be a worthy way to perform the entire OHS project (as an Augment port) goal. I assume the augment code is available in Augment.

We talked about moving the existing data and exporting it from Augment in a way that links would be retained. This was designed from the beginning so that there is a two tier naming system - repository and document name. The idea is that whole repositories can move without the links breaking within a certain namespace. If this is to evolve Data should be portable en mass. Unmoveable knowledge has less value.

Grant Bowman
grant@suse.com
SuSE
580 Second Street, Suite 210
Oakland, CA 94607
510-628-3380 x5027
http://www.suse.com