[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Wasting half a trillion dollars?
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Anatole Tartakovsky <email@example.com>
- Date: Tue, 01 May 2001 10:51:47 -0500
HTML is a document rendering model. Use it for that
and it works fine. Use it handler as a container for
lots of other rich object types and it becomes a
bloated framework. This was not a mystery to the
designers of HyperCard, Mac86, and so on.
There are two stories. One is that the inventor
of Enquire really did have all of this in mind
when the WWW was envisioned. Two is that the
inventor of Enquire had only distributed access
of technical papers in mind. So the history is
muddled and URLs to articles don't help. The
problem is the object framework itself.
MS said in court that IE was required as part of
the core deliverable for the operating system.
Opponents (particularly netscape) said it wasn't.
On the other hand, Netscape with its browser, Sun
with Java, were both busily layering operating
systems on top of operating systems to get
None of this looks like the deliberate design
of a framework to support distributed business
processes or data exchange.
My position then and now is that to
support what people envision for the next generation
of internet systems, one may have to reconsider multiple
client framework designs. MS is moving toward that
and since it controls the dominant means by which
one accesses the internet, I agree that its means
must be considered. On the other hand, it is
also mired in a framework originally envisioned
for document support and one has to ask if it
might not be a good idea to reconsider that.
Do I really need IE or Opera or Netscape or do I need
custom clients, or simply, as in Visual Basic, builder
frameworks? Or by going down that path, do
we lose the homepage builder comfortable with
the lower level of complexity, capable of doing
many things, but not all? Tim Bray claimed developers
have already voted with their feet on this issue.
I do wonder if a recount is in progress.
What that does for inherently stateless protocols
is the next question? Some say the protocol engines
should have no knowledge of the client and don't
need it. It's just a data service. Isn't that
basically what we have now with HTTP?
In other words, as has also been stated before,
the web is HTTP. The rest is product inside
operating systems and some shared data descriptions
A *standard* network enabled operating system becomes
the next generation internet client. That operating system
has to be as generalized as your TV. The Linux people
see this. They don't have the clout to pull it off.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Anatole Tartakovsky [mailto:firstname.lastname@example.org]
One thing I did not mention in my post is HTML, and that is probably
what is causing confusion. Here it goes:
1. I think standard HTML is not usable for application development.
2. Data has to be separated from the presentation on the client - not on
ASP/JSP/Server layer to allow for true application programming
3. New set of rich databound controls has to be introduced and used by