Michael A. Kappler
Daylight CIS, Inc.
Most interface languages reach a limited audience, for example MIT-X, OpenGL, and MSF. Others have a limited lifetime, such as XView and UIL/Motif. The largest audience can be reached using HyperText Transfer Protocol (HTTP). Face-to-face interaction and television aside, the most popular form of communicating of information on planet earth is HTTP over intranets and the internet. With the global trend of internet-ready devices and a wireless world, Shouldn't we all be talking HTTP?
Gee, not too long ago, phrases like "surf the net" and "double-click" were just being born. Now, it's a wonder to imagine a world without the World Wide Web. What interfaces are expected to be here in 5 years? 20 years? 100 years?
If we're in it for the long haul, we need to prepare to haul for a long time. If you're going to sail the seas, you need a strong ship. A raft will not make it far. ROI/T calls for development of tools that are built to last. Biting the bullet now will be a long-term winner.
We'd like to serve stand-alone computers, LANs, WANs, and the World Wide Web. HTTP can travel around the world to any operating system (well, except PlayStation) in a matter of seconds and is independent of hardware architecture. Further, HTTP can carry a variety of languages and data forms, such as HTML, XML, PDFs, TDTs, etc.
HTTP defines enough structure to provide reliable and efficient communication of information. Yet, it is simple and uncomplicated in both theory and practice. The encoding of objects as byte streams carries strong advantages over traditional ASCII streams, and expansion from one to many HTTP services is straightforward.
Browsers are a ubiqitious, full-strength GUI. Does anybody have a computer without one? The client application is already installed. The user learning curve is zero. Build the server and they will come! Also, admistration of HTTP services can be simplified with "out-of-the-box" solutions. Further, support can be reduced by getting away from more complicated CGI configurations and setups. This is especially the true for remotely accessible and configurable services.
The HTTP Toolkit full encapsulates HTTP/1.0 and supports two objects
The HTTP Toolkit features three routines:
Full control is acheived with named properies, which will probably be the basis of Daylight Sotware 5.x.
Focus on strengths, expertise, and experience. The Toolkit should adhere to the Daylight OOP-ish model. The only I/O allowed is over HTTP. At $0.10/MB, applications should be able to compute everything in RAM. The toolkit should deliver data as fast as the physical wire permits. Connect to other services.
Is this reasonable? Why not? We can be backwards compatible (and exonerate ourselves from DayCGI) by migrating to HTTP interfaces. Conversion of lagacy graphic applications may require significant effort. We can be forwards compatible by establishing symantics for unsupported features in protocol and planning named properties in an extensible way. Use simple implementations (text, graphics, links). Plan on mutlithreading and port redirection.