# Enabling Access Modules

The Library comes with a wide set of access modules that gives access to most popular Internet protocols including HTTP, FTP, Gopher, telnet, rlogin, NNTP and WAIS. However, as mentioned in the beginning, when the Library is first initialized it knows nothing about how to access the Internet. In fact it doesn't even know how to access the local file system. It is for the application to tell the Library what it can handle and where to go find the functionality. This is very much the same mechanism as we saw described in the previous chapter, so a lot of what is going on will hopefully become clear as we go along.

All protocol modules are dynamically bound to an access scheme. Take for example the following URL:

    	http://www.w3.org/

It has the access scheme http and if we have a protocol module capable of handling HTTP then we can make the binding between http and this module. As mentioned in the introduction to this chapter, the Library already comes with a large set of protocol module, including HTTP so all we have to do in this case is to register the HTTP module to the Library as being capable of handling http URLs.

Let's see how we can register a protocol module. The support for this is provided by the protocol manager which exports the following function:

    extern BOOL HTProtocol_add (const char *       	scheme,
    			    BOOL		preemptive,
    			    HTEventCallBack *	callback);

This function follows exactly the same naming scheme as we have seen many times before. The first argument the access scheme which the protocol module is capable of handling. This can for example be http, but it can also be non-existent schemes which can be used for experimental protocol implementations, for example whois etc. In case a protocol module is capable of handling more than one access scheme, it can be registered multiple time with different schemes. This is the case with the Telnet access module which also can handle rlogin and tn3270 terminal sessions.

The `preemptive` argument describes to the Library whether it is capable of handling non-blocking sockets or not. This is normally a design decision when implementing the protocol module in that a module implemented for using blocking sockets normally can't use non-blocking sockets. However, the other way is often possible, and in some situations it is advantageous to use blocking sockets. The Library allows this to happen on a pr request basic as explained in the section "The Request Object". The Library Architecture document discusses in more detail how a protocol module can be designed to support non-blocking sockets.

The last argument is the actual function name to call when a request has been issued and a protocol module has been found associated with the access scheme used. Even though it is not clear at this point the `HTEventCallBack` type is a function that the event handler uses in order to initiate requests in the Library.

A protocol module can be disabled at any time during execution. In most cases this is not uses very often but the dynamic nature of the binding leaves this choice free to the application. In case it is desired, you can do so by calling the following function:

    extern BOOL HTProtocol_delete (const char * scheme);

The argument is exactly the same scheme as described above. One special case is the support for access to WAIS databases. WAIS has its own code Library called freeWAIS which is required in order to directly access wais URLs. We shall not describe in describe in detail here how this can be enabled as it is described in the the WWW-WAIS gateway.