Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 marketshare. 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 and languages. <simplisticConclusion> 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. </simplisticConclusion> Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Anatole Tartakovsky [mailto:anatolet@t...] Stuart, 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 application developers.
|
