Outline

• Motivation: Why We Care and Why You Should Too

• Requirements: Let's Try To Get it Right

• Contraints: Simply Go in Special Directions

• Conclusions: What Is and What Will Be

Motivations

• Reach a Wide Audience

  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?

• Use a Long Lasting Interface

  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?

• Maximize Return on Investment over Time (ROI/T)

  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.

Requirements

• Use a Network-Oriented, Platform-Independent Mechanism

  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.

• Make a Reliable, Robust, & Scalable Tool

  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.

• Minimize Installation, Administration & Support

  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.

Contraints

• "Make things simple, but no simplier." - Einstein

  The HTTP Toolkit full encapsulates HTTP/1.0 and supports two objects

  • A HTTP object represent a service, such as SMI2GIF, MOL2SMI, and CLOGP.
  • A TRANSFER object represents messages, such as requests and responses.

  The HTTP Toolkit features three routines:

  • dt_alloc_http_server() creates a service
  • dt_http_get() receives a request message
  • dt_http_put() sends a response message

  Full control is acheived with named properies, which will probably be the basis of Daylight Sotware 5.x.

• Do one thing well, then call for help

  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.

• Be backwards and forwards compatable

  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.

• Link to Daylight's HTTP Toolkit Programmer's Guide

Conclusion

• Motivations for the HTTP Toolkit include reaching a wide audience, using a long-lasting interface, and maximizing ROI/T.
• Requirements are based on network-oritented, platform-independent mechanism that is reliable, robost & scalable, and minimizes installation, administration, & support.
• Constraints for development are keeping it simple, doing one thing well and calling for help, and being backwards & forwards compatible.
• The HTTP Toolkit fully encapsulates HTTP/1.0.
• The Toolkit supports two objects and implements three routines. Full control is acheived with named properties.
• DayCGI replacements are in development.
• Multithreading and port redirection is planned.