<HTML>
<HEAD>
<!-- Changed by: Henrik Frystyk Nielsen, 15-Jul-1996 -->
<TITLE>W3C Sample Code Library libwww Stream Pipe Manager</TITLE>
</HEAD>
<BODY>
<H1>
The Stream Pipe Manager
</H1>
<PRE>
/*
** (c) COPYRIGHT MIT 1995.
** Please first read the full copyright statement in the file COPYRIGH.
*/
</PRE>
<P>
The Stream Pipe Manager is responsible for setting up the stream pipe from
the <A HREF="HTChannl.html">Channel Object</A> to the
<A HREF="HTReq.html">Request Object</A> when data is arriving, for example
as a response to s <A HREF="HTTP.html">HTTP</A> <B>Get</B> request. As data
arrives, we start to parse it and the more we know the more we can build
up our stream pipe. For example, in the case of HTTP, we first have a stream
that can parse the HTTP response line containing "<CODE>200 OK</CODE>". Then
we have a <A HREF="HTMIME.html">MIME parser</A> for handling the MIME headers.
When the MIME headers have been parsed, we know the content type and any
encoding of the MIME body. If we need to decode a chunked encoding then we
set up a chunked decoder, and if we have to parse a HTML object then we set
up a HTML parser.
<P>
The Format Manager is also responsible for keeping track of the
"<I>preferences</I>" of the application and/or user. It is an integral part
of the Web and HTTP, that the client application can express its preferences
as a set of "accept" headers in a HTTP request. This task is highly related
to the task mentioned above as we there use the modules that are registered
and here tell the remote server what we are capable of doing and what we
would prefer.
<P>
<B>Note</B>: The library <B>core</B> does not define any default decoders
or parsers - they are all considered part of the application. The library
comes with a default set of parsers including the ones mentioned above which
can be initiated using the functions in <A HREF="HTInit.html">HTInit
module</A>. There are different initialization functions for content type
parsers and content encodings respectively.
<P>
<UL>
<LI>
<A HREF="#type">Content Type Converters and Presenters</A>
<LI>
<A HREF="#encoding">Content Encoders and Decoders</A>
<LI>
<A HREF="#charset">Content Charsets</A>
<LI>
<A HREF="#language">Natural Languages</A>
</UL>
<P>
The application can assign its preferences in two ways: either <I>locally</I>
to a single request or <I>globally</I> to all requests. The local assignment
can either <I>add to </I>or <I>override</I> the global settings depending
on how they are registered. All local registration is handled by the
<A HREF="HTReq.html">Request Object</A> and the global registration is handled
by the Format Manager.
<P>
This module is implemented by <A HREF="HTFormat.c">HTFormat.c</A>, and it
is a part of the <A HREF="http://www.w3.org/Library/">W3C Sample Code
Library</A>.
<PRE>
#ifndef HTFORMAT_H
#define HTFORMAT_H
#include "<A HREF="HTUtils.html">HTUtils.h</A>"
#include "<A HREF="HTStream.html">HTStream.h</A>"
#include "<A HREF="HTAtom.html">HTAtom.h</A>"
#include "<A HREF="HTList.html">HTList.h</A>"
#include "<A HREF="HTAnchor.html">HTAnchor.h</A>"
#include "<A HREF="HTReq.html">HTReq.h</A>"
</PRE>
<H2>
<A NAME="type">Converters and Presenters</A>
</H2>
<P>
All content type converters are subclassed from the Generic stream objetc.
That way, we allow the application to do very fast progressive display of
incoming data. In other words, the stream model of the Library provides data
as soon as it arrives from the network, the application does not have to
wait until the whole document has been down loaded before it starts parsing
it.
<H3>
Predefined Content Types
</H3>
<P>
These macros (which used to be constants) define some basic internally referenced
representations. The <CODE>www/xxx</CODE> ones are of course not MIME standard.
They are internal representations used in the Library but they can't be exported
to other apps!
<PRE>
#define WWW_INTERNAL HTAtom_for("www/*") /* All internal formats */
</PRE>
<P>
<CODE>WWW_INTERNAL</CODE> represent all internal formats. This can for example
be used to match using the <A HREF="HTWWWStr.html">HTMIMEMatch(...)</A>.
<PRE>
#define WWW_RAW HTAtom_for("www/void") /* Raw output from Protocol */
</PRE>
<P>
<CODE>WWW_RAW</CODE> is an output format which leaves the input untouched
<EM>exactly</EM> as it is received by the protocol module. For example, in
the case of FTP, this format returns raw ASCII objects for directory listings;
for HTTP, everything including the header is returned, for Gopher, a raw
ASCII object is returned for a menu etc.
<PRE>
#define WWW_SOURCE HTAtom_for("*/*")
</PRE>
<P>
<CODE>WWW_SOURCE</CODE> is an output format which leaves the input untouched
<EM>exactly</EM> as it is received by the protocol module <B>IF</B> not a
suitable converter has been registered with a quality factor higher than
1 (for example 2). In this case the <EM>SUPER CONVERTER</EM> is preferred
for the raw output. This can be used as a filter effect that allows conversion
from, for example raw FTPdirectory listings into HTML but passes a MIME body
untouched.
<PRE>
#define WWW_PRESENT HTAtom_for("www/present")
</PRE>
<P>
<CODE>WWW_PRESENT</CODE> represents the user's perception of the document.
If you convert to <CODE>WWW_PRESENT</CODE>, you present the material to the
user.
<PRE>
#define WWW_DEBUG HTAtom_for("www/debug")
</PRE>
<P>
<CODE>WWW_DEBUG</CODE> represents the user's perception of debug information,
for example sent as a HTML document in a HTTP redirection message.
<PRE>
#define WWW_UNKNOWN HTAtom_for("www/unknown")
</PRE>
<P>
<CODE>WWW_UNKNOWN</CODE> is a really unknown type. It differs from the real
MIME type <EM>"application/octet-stream"</EM> in that we haven't even tried
to figure out the content type at this point.
<PRE>
#define WWW_CACHE HTAtom_for("www/cache")
#define WWW_CACHE_APPEND HTAtom_for("www/cache-append")
</PRE>
<P>
<CODE>WWW_CACHE</CODE> is the internal content-type designated for a persistent
cache module which can store the object to local storage. The cache append
format is special in that we append information to an already existing cache
entry. This can happen if we have issued a <CODE>If-Range </CODE>request
and got back a "206 Partial response".
<P>
These are regular MIME types defined. Others can be added!
<PRE>
#define WWW_HTML HTAtom_for("text/html")
#define WWW_PLAINTEXT HTAtom_for("text/plain")
#define WWW_FORM HTAtom_for("application/x-www-form-urlencoded")
#define WWW_MIME HTAtom_for("message/rfc822")
#define WWW_MIME_HEAD HTAtom_for("message/x-rfc822-head")
#define WWW_MIME_FOOT HTAtom_for("message/x-rfc822-foot")
#define WWW_MIME_PART HTAtom_for("message/x-rfc822-partial")
#define WWW_MIME_CONT HTAtom_for("message/x-rfc822-cont")
#define WWW_MIME_UPGRADE HTAtom_for("message/x-rfc822-upgrade")
#define WWW_MIME_COPYHEADERS HTAtom_for("www/x-rfc822-headers")
#define WWW_AUDIO HTAtom_for("audio/basic")
#define WWW_VIDEO HTAtom_for("video/mpeg")
#define WWW_GIF HTAtom_for("image/gif")
#define WWW_JPEG HTAtom_for("image/jpeg")
#define WWW_TIFF HTAtom_for("image/tiff")
#define WWW_PNG HTAtom_for("image/png")
#define WWW_BINARY HTAtom_for("application/octet-stream")
#define WWW_POSTSCRIPT HTAtom_for("application/postscript")
#define WWW_RICHTEXT HTAtom_for("application/rtf")
</PRE>
<P>
We also have some MIME types that come from the various protocols when we
convert from ASCII to HTML.
<PRE>
#define WWW_GOPHER_MENU HTAtom_for("text/x-gopher")
#define WWW_CSO_SEARCH HTAtom_for("text/x-cso")
#define WWW_FTP_LNST HTAtom_for("text/x-ftp-lnst")
#define WWW_FTP_LIST HTAtom_for("text/x-ftp-list")
#define WWW_NNTP_LIST HTAtom_for("text/x-nntp-list")
#define WWW_NNTP_OVER HTAtom_for("text/x-nntp-over")
#define WWW_NNTP_HEAD HTAtom_for("text/x-nntp-head")
#define WWW_HTTP HTAtom_for("text/x-http")
</PRE>
<P>
Finally we have defined a special format for our RULE files as they can be
handled by a special converter.
<PRE>#define WWW_RULES HTAtom_for("application/x-www-rules")
</PRE>
<H3>
The Quality Factor
</H3>
<P>
Characteristic for all preferences is that there is a quality factor associated
with each member. The quality factor is a real number between 0 and 1 with
0 meaning "very bad" and 1 means "perfect". By registering a natural language
or any or other preference in this group together with a quality factor you
can specify "how well the preference is handled" either by the application
or by the user. In the case of the user the quality factor of a natural language
is how well the user understands the language. In my case, the quality factors
for, for example Greek would be close to zero and 1 for Danish (nothing bad
said about Greek!).
<P>
It is a bit different for converters where it is often the application's
ability of handling the data format rather than the user's perception. As
an example it is often faster to use a converter than a presenter as it takes
time to launch the external application and libwww can not use progressive
display mechanisms which is often the case for converters. Therefore, as
an example, if we capable of handling an image in <EM>png</EM> format inline
but rely on an external viewer for presenting postscript, we might set up
the following list:
<P>
<SAMP>HTConversion_add (converters, "image", "www/present", GifPresenter,
<B>1.0</B>, 0.0, 0.0);<BR>
HTPresentation_add (presenters, "application/postscript", "ghostview %s",
NULL, <B>0.5</B>, 0.0, 0.0);></SAMP>
<P>
where the gif converter is registered with a quality factor of <B>1.0</B>
and the postscript presenter with a quality factor of <B>0.5</B>.Register
Presenters
<H3>
The Converter Class
</H3>
<P>
A <CODE>converter</CODE> is a stream with a special set of parameters and
which is registered as capable of converting from a MIME type to something
else (maybe another MIME-type). A converter is defined to be a function returning
a stream and accepting the following parameters. The content type elements
are atoms for which we have defined a prototype.
<PRE>
typedef HTStream * HTConverter (HTRequest * request,
void * param,
HTFormat input_format,
HTFormat output_format,
HTStream * output_stream);
extern void HTConversion_add (HTList * conversions,
const char * rep_in,
const char * rep_out,
HTConverter * converter,
double quality,
double secs,
double secs_per_byte);
extern void HTConversion_deleteAll (HTList * list);
</PRE>
<H3>
The Presenter Class
</H3>
<P>
A <CODE>presenter</CODE> is a module (possibly an external program) which
can present a graphic object of a certain MIME type to the user. That is,
<CODE>presenters</CODE> are normally used to present objects that the
<CODE>converters</CODE> are not able to handle. Data is transferred to the
external program using a special "presenter stream" which for example can
use the local disk to transfer the data from libwww to the external program.
<P>
Libwww provides a default <A HREF="HTFWrite.html">HTSaveAndExecute</A>
stream which you may want to use for this purpose. However, any stream
that is of type <CODE>HTConverter</CODE> will do. You can manage the
special presenter stream using the following methods:
<PRE>
extern void HTPresentation_setConverter (HTConverter * pconv);
extern HTConverter * HTPresentation_converter (void);
</PRE>
Both presenters and converters are of the type
<A HREF="#converter">HTConverter</A>.
<PRE>
extern void HTPresentation_add (HTList * conversions,
const char * representation,
const char * command,
const char * test_command,
double quality,
double secs,
double secs_per_byte);
extern void HTPresentation_deleteAll (HTList * list);
</PRE>
<H3>
Basic Converters
</H3>
<P>
We have a small set of basic converters that can be hooked in anywhere. They
don't "convert" anything but are nice to have.
<PRE>
extern HTConverter HTThroughLine;
extern HTConverter HTBlackHoleConverter;
extern HTConverter HTSaveConverter;
</PRE>
<H2>
<A NAME="encoding">Content and Transfer Encoders and Decoders</A>
</H2>
<P>
Content codins are transformations applied to an entity object after it was
created in its original form. The Library handles two types of codings:
<DL>
<DT>
<B>Content Codings</B>
<DD>
Content codings values indicate an encoding transformation that has been
applied to a resource. Content cosings are primarily used to allow a document
to be compressed or encrypted without loosing the identity of its underlying
media type.
<DT>
<B>Content Transfer Codings</B>
<DD>
Content transfer codings values are used to indicate an encoding transformation
that has been, can be, or may be need to be applied to an enity body in order
to ensure safe transport through the network. This differs from a content
coding in that the transfer coding is a property of the message, not the
original message.
</DL>
<P>
Both types of encodings use the same registration mechanism in the Library
which we describe below:
<H3>
Encoders and Decoders
</H3>
<P>
<EM>Encoders</EM> and <EM>decoders</EM> are subclassed from the
<A HREF="HTStream.html">generic stream class</A>. <EM>Encoders</EM> are capable
of adding a content coding to a data object and <EM>decoders</EM> can remove
a content coding.
<PRE>
typedef HTStream * HTCoder (HTRequest * request,
void * param,
HTEncoding coding,
HTStream * target);
</PRE>
<P>
The <EM>encoding</EM> is the name of the encoding mechanism reporesented
as an <A HREF="HTAtom.html">atom</A>, for example "zip", "chunked", etc.
Encodings are registered in lists and content encodings are separated from
transfer encodings by registering them in different lists.
<H3>
Basic Encoders
</H3>
<P>
We have a small set of basic coders that can be hooked in anywhere.
<PRE>
extern HTCoder HTIdentityCoding;
</PRE>
<H3>
The HTCoding Object
</H3>
<P>
The <EM>HTCoding</EM> object represents a registered encoding together with
a encoder and a decoder.
<PRE>
typedef struct _HTCoding HTCoding;
</PRE>
<P>
Predefined Coding Types We have a set of pre defined atoms for various types
of content encodings and transfer encodings. "chunked" is not exactly in
the same group as the other encodings such as "binary" but it really doesn't
make any difference as it is just a matter of how the words are chosen. The
first three transfer encodings are actually not encodings - they are just
left overs from brain dead mail systems.
<PRE>
#define WWW_CODING_7BIT HTAtom_for("7bit")
#define WWW_CODING_8BIT HTAtom_for("8bit")
#define WWW_CODING_BINARY HTAtom_for("binary")
#define WWW_CODING_IDENTITY HTAtom_for("identity")
#define WWW_CODING_BASE64 HTAtom_for("base64")
#define WWW_CODING_MACBINHEX HTAtom_for("macbinhex")
#define WWW_CODING_CHUNKED HTAtom_for("chunked")
#define WWW_CODING_COMPRESS HTAtom_for("compress")
#define WWW_CODING_GZIP HTAtom_for("gzip")
#define WWW_CODING_DEFLATE HTAtom_for("deflate")
</PRE>
<H3>
Register Content Coders
</H3>
<P>
Some documents are not send in their original data obejct but is encoded
in some way. On the Web this is mostly some kind of compression but other
encodings for example base 64 can be encountered when talking to NNTP servers
etc. Just as for the other preferences, an application can register a supported
encoders or decodes as a list. Encoders and decoders are registered in the
same way with no differentiation whether it is a encoder or a decoder:
<PRE>
extern BOOL HTCoding_add (HTList * list,
const char * encoding,
HTCoder * encoder,
HTCoder * decoder,
double quality);
extern void HTCoding_deleteAll (HTList * list);
extern const char * HTCoding_name (HTCoding * me);
extern double HTCoding_quality (HTCoding * me);
</PRE>
<H2>
<A NAME="charset">Content Charsets</A>
</H2>
<P>
As the Web reaches all parts of the Internet there are more and more documents
written in languages which contains characters not included in the ISO-8859-1
character set. A consequence of this the set of characters sets is often
tightly connected with the natural language. libwww does not directly support
other character sets but in case an application is capable of handling
alternative sets it can register these as preferred character sets along
with a quality factor just as all the other preferences in this section.
<PRE>extern void HTCharset_add (HTList * list, const char * charset, double quality);
</PRE>
<PRE>typedef struct _HTAcceptNode {
HTAtom * atom;
double quality;
} HTAcceptNode;
</PRE>
<PRE>
extern void HTCharset_deleteAll (HTList * list);
</PRE>
<H2>
<A NAME="language">Content Languages</A>
</H2>
<P>
The preferred natural language or languages is in almost all situations dependent
on the individual user and an application should therefore give the user
the opportunity to change the setup. When specifying a natural language
preference, libwww will send this preference along with all HTTP requests.
The remote server will then (it if supports this feature) look for a version
in the language or languages mentioned. If it finds a matching document then
it returns this one, otherwise it uses the best alternative. If no language
is specified the remote server may whatever version it finds.
<PRE>extern void HTLanguage_add (HTList * list, const char * lang, double quality);
extern void HTLanguage_deleteAll (HTList * list);
</PRE>
<H2>
<A NAME="global">Global Preferences</A>
</H2>
<P>
There are two places where these preferences can be registered: in a
<EM>global</EM> list valid for <B>all</B> requests and a <EM>local</EM> list
valid for a particular request only. These are valid for <EM>all</EM> requests.
See the <A HREF="HTReq.html">Request Manager</A> fro local sets.
<H3>
Global Converters and Presenters
</H3>
<P>
The <EM>global</EM> list of specific conversions which the format manager
can do in order to fulfill the request. There is also a
<A HREF="HTReq.html"><EM>local</EM></A> list of conversions which contains
a generic set of possible conversions.
<PRE>extern void HTFormat_setConversion (HTList * list);
extern HTList * HTFormat_conversion (void);
extern void HTFormat_addConversion (const char * input_format,
const char * output_format,
HTConverter * converter,
double quality,
double secs,
double secs_per_byte);
</PRE>
<H3>
Global Content Codings
</H3>
<PRE>extern void HTFormat_setContentCoding (HTList * list);
extern HTList * HTFormat_contentCoding (void);
extern BOOL HTFormat_addCoding ( char * encoding,
HTCoder * encoder,
HTCoder * decoder,
double quality);
</PRE>
<P>
We also define a macro to find out whether a content encoding is really an
encoding or whether it is a unity encoder.
<PRE>
#define HTFormat_isUnityContent(me) \
((me)==NULL || \
(me)==WWW_CODING_BINARY || (me)==WWW_CODING_IDENTITY || \
(me)==WWW_CODING_7BIT || (me)==WWW_CODING_8BIT)
</PRE>
<H3>
Global Transfer Codings
</H3>
<PRE>extern void HTFormat_setTransferCoding (HTList * list);
extern HTList * HTFormat_transferCoding (void);
extern BOOL HTFormat_addTransferCoding ( char * encoding,
HTCoder * encoder,
HTCoder * decoder,
double quality);
</PRE>
<P>
We also define a macro to find out whether a transfer encoding is really
an encoding or whether it is just a "dummy" as for example 7bit, 8bit, and
binary.
<PRE>
#define HTFormat_isUnityTransfer(me) \
((me)==NULL || \
(me)==WWW_CODING_BINARY || (me)==WWW_CODING_IDENTITY || \
(me)==WWW_CODING_7BIT || (me)==WWW_CODING_8BIT)
</PRE>
<H3>
Global Content Languages
</H3>
<PRE>extern void HTFormat_setLanguage (HTList * list);
extern HTList * HTFormat_language (void);
</PRE>
<H3>
Global Content Charsets
</H3>
<PRE>extern void HTFormat_setCharset (HTList * list);
extern HTList * HTFormat_charset (void);
</PRE>
<H3>
Delete All Global Lists
</H3>
<P>
This is a convenience function that might make life easier.
<PRE>extern void HTFormat_deleteAll (void);
</PRE>
<H2>
<A NAME="CTStack">The Content Type Stream Stack</A>
</H2>
<P>
This is the routine which actually sets up the content type conversion. It
currently checks only for direct conversions, but multi-stage conversions
are forseen. It takes a stream into which the output should be sent in the
final format, builds the conversion stack, and returns a stream into which
the data in the input format should be fed. If <CODE>guess</CODE> is true
and input format is <CODE>www/unknown</CODE>, try to guess the format by
looking at the first few bytes of the stream.
<PRE>
extern HTStream * HTStreamStack (HTFormat rep_in,
HTFormat rep_out,
HTStream * output_stream,
HTRequest * request,
BOOL guess);
</PRE>
<H3>
Cost of a Stream Stack
</H3>
<P>
Must return the cost of the same stack which HTStreamStack would set up.
<PRE>
extern double HTStackValue (HTList * conversions,
HTFormat format_in,
HTFormat format_out,
double initial_value,
long int length);
</PRE>
<H2>
<A NAME="CEStack">Content Encoding Stream Stack</A>
</H2>
<P>
When creating a coding stream stack, it is important that we keep the right
order of encoders and decoders. As an example, the HTTP spec specifies that
the list in the <EM>Content-Encoding</EM> header follows the order in which
the encodings have been applied to the object. Internally, we represent the
content encodings as <A HREF="HTAtom.html">atoms</A> in a linked
<A HREF="HTList.html">list object</A>.
<P>
The creation of the content coding stack is not based on quality factors
as we don't have the freedom as with content types. When using content codings
we <EM>must</EM> apply the codings specified or fail.
<PRE>
extern HTStream * HTContentCodingStack (HTEncoding coding,
HTStream * target,
HTRequest * request,
void * param,
BOOL encoding);
</PRE>
<P>
Here you can provide a complete list instead of a single token. The list
has to be filled up in the order the _encodings_ are to be applied
<PRE>
extern HTStream * HTContentEncodingStack (HTList * encodings,
HTStream * target,
HTRequest * request,
void * param);
</PRE>
<P>
Here you can provide a complete list instead of a single token. The list
has to be in the order the _encodings_ were applied - that is, the same way
that _encodings_ are to be applied. This is all consistent with the order
of the Content-Encoding header.
<PRE>
extern HTStream * HTContentDecodingStack (HTList * encodings,
HTStream * target,
HTRequest * request,
void * param);
</PRE>
<H2>
<A NAME="TEStack">Transfer Encoding Stream Stack</A>
</H2>
<P>
When creating a coding stream stack, it is important that we keep the right
order of encoders and decoders. As an example, the HTTP spec specifies that
the list in the <EM>Transfer-Encoding</EM> header follows the order in which
the encodings have been applied to the object. Internally, we represent the
content encodings as <A HREF="HTAtom.html">atoms</A> in a linked
<A HREF="HTList.html">list object</A>.
<P>
The creation of the content coding stack is not based on quality factors
as we don't have the freedom as with content types. When using content codings
we <EM>must</EM> apply the codings specified or fail.
<PRE>
extern HTStream * HTTransferCodingStack (HTEncoding coding,
HTStream * target,
HTRequest * request,
void * param,
BOOL encoding);
</PRE>
<P>
Here you can provide a complete list instead of a single token. The list
has to be filled up in the order the _encodings_ are to be applied
<PRE>
extern HTStream * HTTransferEncodingStack (HTList * encodings,
HTStream * target,
HTRequest * request,
void * param);
</PRE>
<P>
Here you can provide a complete list instead of a single token. The list
has to be in the order the _encodings_ were applied - that is, the same way
that _encodings_ are to be applied. This is all consistent with the order
of the Transfer-Encoding header.
<PRE>
extern HTStream * HTTransferDecodingStack (HTList * encodings,
HTStream * target,
HTRequest * request,
void * param);
</PRE>
<H2>
<A NAME="CTEStack">Transfer Encoding Stream Stack</A>
</H2>
<P>
Creating the transfer content encoding stream stack is not based on quality
factors as we don't have the freedom as with content types. Specify whether
you you want encoding or decoding using the BOOL "encode" flag.
<PRE>
extern HTStream * HTContentTransferCodingStack (HTEncoding encoding,
HTStream * target,
HTRequest * request,
void * param,
BOOL encode);
</PRE>
<H3>
Presentation Object
</H3>
<P>
This object is not to be used - it should have been hidden
<PRE>typedef struct _HTPresentation {
HTFormat rep; /* representation name atomized */
HTFormat rep_out; /* resulting representation */
HTConverter *converter; /* The routine to gen the stream stack */
char * command; /* MIME-format string */
char * test_command; /* MIME-format string */
double quality; /* Between 0 (bad) and 1 (good) */
double secs;
double secs_per_byte;
} HTPresentation;
</PRE>
<PRE>
#endif /* HTFORMAT */
</PRE>
<P>
<HR>
<ADDRESS>
@(#) $Id: HTFormat.html,v 2.84.2.1 2001/08/30 13:57:59 kahan Exp $
</ADDRESS>
</BODY></HTML>
Webmaster
![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to HTFormat.html CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Public] / libwww / Library / src