# Bindings to the local File system

The preferences that we described in section Request Preferences did not mention what the Library should do if it doesn't know the data format of a document. In many protocols this information is provided by the remote server. Typical examples are MIME like protocols where the metainformation such as the Content-Type and the Content-Language is provided together with the document. However, applications often have access to the local file system using file URLs which in general do not keep any or at least very little information of the file type. It is therefore required to have some kind of binding between the file system and the preferences registered in the Library which provides this mateinformation about the object.

Often files in a file system is classified by some sort of a suffix, for example GIF files are often ending in .gif, text files in .txt etc. This binding is not static and it is therefore required to have a dynamic binding just like the preferences themselves. An example of the latter is HTML files which on most Unix systems end in .html whereas they on many MS-DOS based systems end in .htm.

The HTBind module provides a generic binding mechanism between a file and its representation internally in the Library. It is not limited to simple file suffix classification but can also be used in more advanced environments using data bases etc. However, at this point we are interested in how we can register bindings between file suffixes and for example content types, content languages etc.

Before starting a more detailed description of how to register file suffixes, it might be required to define what actually is a file suffix and what is the set of delimiters separating them on a particular platform. The Bind manager is born with a certain knowledge about the set of delimiters but more can be added to provide the functionality desired. This can be done using the following function:

    extern void HTBind_caseSensitive	(BOOL sensitive);

where sensitive can either be YES or NO. Also the set of delimiters can be defined using the following function:

    extern const char *HTBind_delimiters	(void);
    extern void HTBind_setDelimiters	(const char * new_suffixes);

Examples of a list of suffixes are

    	"._"
    	"."
    	"._-"

Note that the suffixes chosen do not have to be connected with what is available on a particular platform. However, a certain coupling will probably make maintenance of the file system easier for all parties. In the following we will show the API for adding bindings between the preferences and the file system. You can add a binding between a Content type and a suffix by using the following function:

    extern BOOL HTBind_addType	(const char *	suffix,
    				 const char *	format,
    				 double		value);

Calling this with suffix set to "*" will set the default representation which is used in case no other suffix fits the actual file. Using a suffix set to "*.*" will set the default representation for unknown suffix files which contain a "." The format argument is exactly like described in the section Request Preferences. In exactly the same way you can add a binding between an encoding anda file suffix using the following function:

    extern BOOL HTBind_addEncoding	(const char *	suffix,
    				 const char *	encoding,
    				 double		value);

Bindings can also be made between a file suffix and a specific natural language:

    extern BOOL HTBind_addLanguage	(const char *	suffix,
    				 const char *	language,
    				 double		value);

In all cases, it should be mentioned, that any of the suffixes can contain characters that normally must be escaped in a URL, for example space < >. However, they should not be encoded when parsed as the `suffix` parameter but left as is.