Date: 12 Aug 2000 00:28:28 -0700

From:	Grant Bowman
	grant@suse.com

Reply-To: ohs-dev@bootstrap.org

To:	ohs-dev@bootstrap.org

Subject:

Basic Browser Requirements?

[Responding to Eric Armstrong's letter on August 11, 2000...]

I have a few thoughts that may or may not help clarify.

I think we have several different "foreground images" we are trying to focus on at different times and with different people at the same time. I hope we can recognize this get segment our discussion ideas into appropriate levels that fir the architecture of the system.

John, while I value your comments and I do want to see it all captured (ideally on the Wiki, let me know when I can help) and used later on, I think the timing of your comments or perhaps the lack of structure to the differnet levels of discussion are getting in the way somehow.

First, we need to define a target audience for version 1a, the first gross and clunky code we get running. Later, intermediate goals between "code now" and "DKR" need to be mapped out. I think this 1a discussion may be best carried out on this ohs-dev mail list.

I suspect it would include an architecture for flexibility between XML & browsers.

Second and most important, all of these issues may be enhanced or mitigated by discussing the partitioning of the OHS application as mentioned by Eric below. The whole idea is to write some kind of "plug-ins" to allow different interfaces or views. I think this is one discussion where we can all be right! just not at the same time!?!

Let's just start to get it solidified a bit how to get XML -> OHS compatible browsers/software.

A sample of what I mean by partitioning the applications. Each of these items represent a seperate physical box or computer. We can confuse things later by lumping functions onto fewer machines. Using some kind of RMI or CORBA between the database server, object server and Java servlets should give scalability with a good object broker system.

Date: 11 Aug 2000 21:09:00

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

Reply-To: ohs-dev@bootstrap.org

To: ohs-dev@bootstrap.org

Subject:

Basic Browser Requirements?

I've been giving some thought to our basic browser requirements. Basically, I'm not sure we're on the right track. (If the problems I perceive don't exist, I hope someone will 'splain it to me...in small words.)

At the moment, we have accepted as "given" that we will allow the archived to be browsed with NS4.0/MSIE4.0. I'm not sure that's wise. Here's why:

• They offer a lower level of functionality that that offered by 6.0/XML-based versions.

• They are not customizable or programmable.

  We want the system to evolve -- we want people developing more and better clients, all of which use the underlying system as a base, so it becomes a standard for information interchange.

• We say, on the one hand, that we want to deliver raw XML to the clients, so they can do the processing locally. On the other hand, we plan to implement the view-manipulation logic on the server side. But I don't see how we can do both, unless we have two virtually-identical systems. That's a maintenance headache.

• Peformance will, in a word, suck.

  Zwicki proved that to me. I can't get to it from inside Sun's firewall. So I got to it from my 38.8 modem at home. *That* performance was terrible. If we implement OHS this way, it will be regarded as a somewhat interesting toy -- not as a usable application.

Thoughts on that subject:

• As already mentioned, performance will limit those who access the system anyway.

• If we were talking about a software package that cost several hundred dollars, that had to be acquired on a CD, then yes, we could expect that users would be slow to upgrade. But we live in Internet time, nowadays. If these browsers are what they are cracked up to be, they will effectively replace their predecessors in 12-18 months -- time during which we will be doing most of our development anyway.

• In the early stages of this system, we really want the "early adopters" -- people who like trying new technologies, who are relatively tolerant of flaws. We really do NOT want people with high expectations for flawless execution and rapid performance at the outset. People who are using the new browsers fit that bill perfectly. Our user base can grow right along with acceptance of those browsers, our application will help push that acceptance curve.

  
  

Eric Armstrong
eric.armstrong@eng.sun.com