One of the most successful aspects of the web is that the user interacts with the environment with much of the underlying infrastructure hidden. Details of protocols, routers, domain name servers, and the like are largely hidden from view.
HTML includes some of the typical things that you would expect in a page description language. You can specify text color, font size, and alignment. You can place graphics and use tables. HTML also omits some things that you may find quite suprising. It can be difficult to control exact placement of characters. There is limited control of font styles. And elements like flowing columns and page breaks are non-existant. Most of these limitations stem from the original days of HTML where HTML was a layout language designed for publishing arcane computer documentation.
Most of the complexity of modern-day HTML usage stems from web page designers trying to produce visually appealing page layouts using a language that does not lend itself well to page layouts. As such, a number of HTML features are now used in manners that are very strange indeed. For example, if you wish to layout a page with two columns, you create an HTML document that defines a table and use each table cell as a column.
One of the other problems, as well as one of the strengths, of HTML is that the finished document may display differently depending on the client that is in use. These variances can be due to screen resolutions, the version of browser software in use, and other factors. While this at first appears to be a severe handicap, it is actually a big bonus as well. You see, web pages that display on a 1024x768 high-resolution computer monitor are still usable at 300x200 on Web TV.
This whole operation is very batch oriented. A single request is transmitted from the client to the host and the host responds with a single response. In the first implementation of HTTP (version 0.9), an individual TCP/IP stream connection would be opened and closed for each request/response transaction. With later versions of HTTP, this individual connection could be maintained for longer periods to improve performance. Being batch oriented again has its benefits and problems. With the public internet, performance can have very high latency. This means that even though the amount of data that can be moved from point to point may be high, it may still take a long time for the data to get there. By running in screen-at-a-time batch mode, this latency has minimal effects on the usefulness of the application. The downside of batch mode is that it is batch mode. Interactive conversations with the host are not supported except when requesting a completely new page. This can make conversing with a user somewhat less efficient than a traditional terminal or windows GUI application.
The web really gets interesting when it's use goes beyond static content. In this case, the users is not only displaying pre-built information, but also interactively using dynamic information that is the result of their input. Dynamic web content is probably more accurately referred to as a "web application". The host (web server) not only stores pre-built HTML and image files, but also stores database and program files that allow the user to dynamically interact.
These web servers provide APIs (Application Programming Interfaces) that allow you to write programs that interace with the web servers. These APIs are not designed to interace directly with the MultiValue database environment and either require database access through SQL and ODBC, or require scripts using Common Gateway Interconnections (CGI) or 'C' programs to pass data to and from the MultiValue environment. This results in a multi-layer environment that only adds complexity and overhead in accessing your MultiValue data and applications.
{INCLUDE _WEB_FTR.HTM}