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.
-- Grant
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
http://ohs.sourceforge.net/SourceForge30Jun00.ppt
http://www.bootstrap.org:8080/OHS/N-squared%20Interface%20Diagram
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.
Features important to "extended jumps" are: * clear noun/verb language
allowing extensibility, * noun/verb should naturally map to object and
method * indirect linking, * implicit linking, * macros.
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 +1-510-628-3380 x5027 -- 580 Second Street, Suite 210 fax +1-510-628-3381 -- Oakland, CA 94607 http://www.suse.com
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:56 PDT