] Two non-PhD's (one of them an undergrad) working at a government
] research lab essentially knocked out Mosaic in 3 months. In other
] words, it could do a lot of good.
This reminds me of the "two schools" of design that frequently
become flash points at international conferences:
The American School:
Successful examples first -> then standards
The European School:
Standards first -> then implementations
Obviously this is a bit of an oversimplification - but as many
stereotypes, there sometimes is a grain of truth there.
I come from Marc's school. Literally. I was an undergrad at the Univ of
Ill. from 1974-78. I spent literally thousands of hours on PLATO. And
so did Ray Ozzie, Len Kawell, and Tim Halvorsen, all classmates of mine
and who went on to create DECnotes and later Lotus Notes. It's
definitely a schooling in the "American School" of software. Good
training. Knock out good products and you will become a standard.
But there is something to be said for the "European school". A
standard interface, a standard API, is a platform on which many good
things can grow. For example, once HTTP was fairly stable, people felt
comfortable going off and building WWW clients. Once the CGI interface
is stable, one will see people invest in building scripts.
Few people want to stick things directly into the Mosaic or TkWWW
client. Mainly because they continue to evolve so fast. That is why
there are interface "standards". The solidfy a fixed interface, and
allow good "accessories" to flourish. A booming OEM market, so to
speak.
In my Accesories proposal I pointed out the shortcomings of the VCI
(Viewer Client Interface). I proposed how a small change could result
in an ACI (Accessories Client Interface). In such a scheme many
current Mosaic tools (document viewer, hotlist viewer and eventual HTML
editor) could be OEM'ed. A big win in maintenance for the NCSA staff.
Not only that, but since the interface would be a bi-directional
continous stream of MIME objects a lot of nomadic applications could be
spawned (and I have mentioned several for PDA, automatic form fillers,
etc).
Since I don't "own" a client, I can't directly imbed the interface into
any client. Unless I want to get saddled with a continous maintenance
function (which my management will not allow). Besides what I want to
work on are the accessories themselves, but once a well developed
protocol is in place.
Luckily, there are plenty of people in www land who can beat this
proposal into shape - and I have no particular attachment to my ideas
or the chutzpah to think that I have the only solution. (Indeed, as I
pointed out, I think both the CGI and ACI will have to migrate
eventually to a more CORBA or OLE like mechanism).
All we need is agreement from the client builders that this is a "good
thing" and that it's worth the effort to create an Internet Draft.
BTW: I do come from the U of I school, so I have already started
work on a "hack" to the viewer mechanism that gives two-way communicaiton
by embedding TCL-DP sends into HTML documents.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yechezkal-Shimon Gutfreund sgutfreund@gte.com [MIME]
GTE Laboratories, Waltham MA http://www.gte.com/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=