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.
Database or XML data
|
V
Database Server, SQL
servicing routines, DOM access(?), etc.
|
V
"Object Server"
Business Logic - if certain view selected, cut the XML up this way...
|
V
Java Servlets that speak with the object server
HTML code generated to send to the browsers
Maybe there are XSL here
Apache HTTPD
|
V
Browser running HTML & Javascript
GUI functioning performed.
Maybe XML Direclty with XSL.
I will try to put this on the wiki soon.
This way we can have one set of servers up to the object server and have
different architectures going forward. It sounds like the latest and
modern browsers can skip the step between object server and browser and
link them directly.
I can imagine a WAP Voice front end between the object server and a
cellular telephone browser or cellular telephone voice response.
Did I represent the technological elements accurately in this scenario?
Comments?
-- Grant
* Eric Armstrong <eric.armstrong@eng.sun.com> [000811 21:09]:
> 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.
>
> In return for saddling ourselves with the reduced functionality
> those clients represent, what do we get? More access by more
> people? Maybe. And maybe not. 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.
-- -- 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:49 PDT