Annotation of libwww/Library/src/WWWApp.html, revision 2.4
2.1 frystyk 1: <HTML>
2: <HEAD>
2.2 frystyk 3: <TITLE>Non-Mandatory Application Include File</TITLE>
2.3 frystyk 4: <!-- Changed by: Henrik Frystyk Nielsen, 16-Nov-1995 -->
2.1 frystyk 5: <NEXTID N="z11">
6: </HEAD>
7: <BODY>
8:
2.2 frystyk 9: <H1>Non-Mandatory Application Include File</H1>
2.1 frystyk 10:
11: <PRE>
12: /*
13: ** (c) COPYRIGHT MIT 1995.
14: ** Please first read the full copyright statement in the file COPYRIGH.
15: */
16: </PRE>
17:
18: In addition top the basic W3C Reference Library include file called <A
19: HREF="WWWLib.html">WWWLib.h</A> you <EM>can</EM> also include this
20: file called WWWApp.h depending on the needs of your
21: application. However, it is not required and none of the files
22: included below are ever used in the core part of the Library
23: itself. Only if this file is included, the extra modules will get
24: included in the linked object code. It is also possible to include
25: only a subset of the files below if the functionality you are after is
26: covered by them.
27:
28: <PRE>
29: #ifndef WWWAPP_H
30: #define WWWAPP_H
31: </PRE>
32:
33: <PRE>
34: #ifdef __cplusplus
35: extern "C" {
36: #endif
37: </PRE>
38:
39: <H2>Initialization</H2>
40:
41: The core parts of the Library is a framework for adding
2.3 frystyk 42: functionality. It has hooks for adding protocol modules, like for
2.1 frystyk 43: example HTTP, FTP, and also for adding streams that can convert from
44: one media type to some other type, or presenting the result to the
45: user. In the distribution file of the Library you will find a large
2.3 frystyk 46: set of protocol modules and streams already implemented. However, in
2.1 frystyk 47: order to use these you need to initialize them. This can be done by
48: using the files in the <A HREF="HTInit.html">HTInit</A> module. You
49: can modify this module as you like to fit your particular needs.
50:
51: <PRE>
2.2 frystyk 52: #include "<A HREF="HTInit.html">HTInit.h</A>"
53: </PRE>
54:
2.3 frystyk 55: <H3>Generating the First Anchor</H3>
2.2 frystyk 56:
57: This module provides some "make life easier" functions in order to get
58: the application going. They help you generate the first anchor, also
59: called the <EM>home anchor</EM>. It also contains a nice set of
60: default WWW addresses.
61:
62: <PRE>
63: #include "<A HREF="HTHome.html">HTHome.h</A>"
2.1 frystyk 64: </PRE>
65:
2.3 frystyk 66: <H2>Before a Request</H2>
67:
2.4 ! frystyk 68: When a request has been issued there are a number of things that an
2.3 frystyk 69: application might want to do with the request before it actually goes
70: on the wire, for example to talk to a remote HTTP server. Examples are
71: checking if the object already is kept in a cache managed by the
72: application, if the request should be redirected to a proxy or a
73: gateway, or there is some other kind of translation of the URL taking
74: place. The Library provides a variety of modules that handles many
75: common place translations such as <EM>redirection of URLs</EM> and
2.4 ! frystyk 76: <EM>caching</EM>.<P>
2.3 frystyk 77:
78: These modules are not part of the <A HREF="WWWCore.html">Library
79: Core</A> as the registration process depends on the application. It
80: can for example use a database or some other means of registering
81: translation rules, proxy servers. etc. The Library implementations are
82: deliberately made as platform independent as possible and will cover
2.4 ! frystyk 83: most situations. You can find a function called
! 84: <CODE>HTLoadStart</CODE> in the <A HREF="HTHome.h">HTHome module</A>
! 85: that enables all the functionality for translating URLs.
2.3 frystyk 86:
87: <H3>Rule File Management</H3>
88:
89: Another way to initialize applications is to use a rule file, also
90: known as a configuration file. This is for example the case with the
91: W3C httpd and the W3C Line Mode Browser. This module provides basic
92: support for configuration file management and the application can use
93: this is desired. The module is not referred to by the Library. Reading
94: a rule file is implemented as a stream converter so that a rule file
95: can come from anywhere, even across the network!
96:
97: <PRE>
98: #include "<A HREF="HTRules.html">HTRules.h</A>"
99: </PRE>
100:
101: <H3>Proxies and Gateways</H3>
102:
103: Applications do not have to provide native support for all protocols,
104: they can in many situations rely on the support of proxies and
105: gateways to help doing the job. Proxy servers are often used to carry
106: client requests through a firewall where they can provide services
107: like corporate caching and other network optimizations. Both Proxy
108: servers and gateways can serve as "protocol translators" which can
109: convert a request in the main Web protocol, HTTP, to an equivalent
110: request in another protocol, for example NNTP, FTP, or Gopher. In case
111: a proxy server or a gateway is available to the application, it can
112: therefore by use of HTTP forward all requests to for example a proxy
113: server which then handle the communications with the remote server,
114: for example using FTP about the document and return it to the
115: application (proxy client) using HTTP.
116:
117: <PRE>
118: #include "<A HREF="HTProxy.html">HTProxy.h</A>"
119: </PRE>
120:
121: <H3>Cache Manager</H3>
122:
123: Caching is a required part of any efficient Internet access
124: applications as it saves bandwidth and improves access performance
125: significantly in almost all types of accesses. The Library supports
126: two different types of cache: The memory cache and the file cache. The
127: two types differ in several ways which reflects their two main
128: purposes: The memory cache is for short term storage of graphic
129: objects whereas the file cache is for intermediate term storage of
130: data objects. Often it is desirable to have both a memory and a file
131: version of a cached document, so the two types do not exclude each
132: other.
133:
134: <PRE>
135: #include "<A HREF="HTCache.html">HTCache.h</A>"
136: </PRE>
137:
138: <H2>After a Request</H2>
139:
140: When a request is terminated, the application often has to do some
141: action as a result of the request (and of the result of the
142: request). The Application part of the Library provides two following
143: modules to handle <EM>logging</EM> and <EM>history
144: management</EM>. You can register a <EM>POST request handler</EM> in
145: the <A HREF="HTNet.html">Net Manager</A> as described in the <A
2.4 ! frystyk 146: HREF="../User/Using/Overview.html">User's Guide</A>. <P>
! 147:
! 148: You can find a function called <CODE>HTLoadTerminate</CODE> in the <A
! 149: HREF="HTHome.h">HTHome module</A> that enables all the functionality
! 150: for handling a request result.
2.3 frystyk 151:
152: <H3>Logging</H3>
2.1 frystyk 153:
154: Often it is required to log the requests issued to the Library. This
155: can either be the case if the application is a server or it can also
156: be useful in a client application. This module provides a simple
157: logging mechanism which can be enabled if needed.
158:
159: <PRE>
2.2 frystyk 160: #include "<A HREF="HTLog.html">HTLog.h</A>"
2.1 frystyk 161: </PRE>
162:
2.3 frystyk 163: <H3>History Management</H3>
2.1 frystyk 164:
165: Another type of logging is keeping track of which documents a user has
166: visited when browsing along on the Web. The Library history manager
167: provides a basic set of functionality to keep track of a linear
168: history list.
169:
170: <PRE>
2.2 frystyk 171: #include "<A HREF="HTHist.html">HTHist.h</A>"
2.1 frystyk 172: </PRE>
173:
174: End of application specific modules
175:
176: <PRE>
177: #ifdef __cplusplus
178: } /* end extern C definitions */
179: #endif
180:
181: #endif
182: </PRE>
183:
184: End of WWWAPP definition
185:
186: </BODY>
187: </HTML>
Webmaster