Roxen.git / server / etc / include / config.h

version» Context lines:

Roxen.git/server/etc/include/config.h:1:   /* -*- Pike -*- -  * $Id: config.h,v 1.14 1998/04/26 17:18:54 per Exp $ +  * $Id: config.h,v 1.15 1999/07/15 16:59:28 neotron Exp $    *    * User configurable things not accessible from the normal    * configuration interface. Not much, but there are some things..    */      #include <extra_config.h>   #ifndef _ROXEN_CONFIG_H_   #define _ROXEN_CONFIG_H_      
Roxen.git/server/etc/include/config.h:79:   #endif      /* Do we want module level deny/allow security (IP-numbers and usernames).    * 1% speed loss, as an average. (That is, if your CPU is used to the max.    * it probably isn't..)    */   #ifndef NO_MODULE_LEVEL_SECURITY   # define MODULE_LEVEL_SECURITY   #endif    + /* If this is disabled, the server won't parse the supports string. This might +  * make the server somewhat faster. If you don't need this feature but need the +  * most speed you can get, it might be a good idea to disable supports. +  */ +  + // #define DISABLE_SUPPORTS +  +  + /* If this is disabled, the server won't do virtual hosting, meaning many +  * servers using the same IP. Another option that somewhat speeds up the +  * server. +  */ +  + // #define DISABLE_VIRTUAL_HOSTING +  +    /* Roxen neighbourhood    *    * Experimental. Currently does not work on all Operating Systems. -  +  * *** WARNING *** There are reports of this not working at all. It's +  * not supported, not maintained and CAN LOCK UP YOUR SERVER!    */   // #define ENABLE_NEIGHBOURHOOD      /* If set, the maximum, minimum and average time used to serve    * requests is logged.    * This (rusage()) is broken on some systems, and the server will be    * somewhat ( < 5% ) slower with this enabled.    *    * CURRENTLY NOT SUPPORTED, WORK IN PROGRESS, It _did_ work in 1.0b4 :-)    */
Roxen.git/server/etc/include/config.h:130:      #endif /* if _ROXEN_CONFIG_H_ */      /* Should we be compatible with level b9 and below configuration files? */   #undef COMPAT      /*    * Should support for URL modules be included?    * I am trying to phase them out, but..    */ - #define URL_MODULES + // #define URL_MODULES      /* Basically, should it be o.k. to return "string" as a member of    * the result mapping? This is only for compability.    * Normally: ([ "data":long_string, "type":"text/html" ]), was    * ([ "string":long_string, "type":"text/html" ]), please ignore..    * Do not use this, unless you _really_ want to make your    * modules unportable :-)    */   #undef API_COMPAT