libs/synapse/doc/runtime.txt

   1 XML config files for customized synapse initialization at runtime\r
   2 -----------------------------------------------------------------\r
   3 \r
   4 Objective:\r
   5 ----------\r
   6 \r
   7 We have to assign the minors of the APIs to function tables \r
   8 (and possibly to the API managers) at runtime from some config files.\r
   9 \r
  10 For instance in Q3 or RTCW mode, we will want to fill in \r
  11 g_FileSystemTable and g_ShadersTable with the "quake3" minor. Whereas\r
  12 those tables will be filled in with a different minor for HL mode.\r
  13 \r
  14 This affects SYN_REQUIRE for all the clients of the system, so that\r
  15 config will need to be global and passed around to the clients.\r
  16 \r
  17 Implementation:\r
  18 ---------------\r
  19 \r
  20 an XML hierarchy to describe the APIs:\r
  21 <client name="CORE">\r
  22   <api name="vfs">\r
  23     quake3\r
  24   </api>\r
  25   <api name="shaders">\r
  26     quake3\r
  27   </api>\r
  28   ..\r
  29 </client>\r
  30 <client name="SHADERS">\r
  31   \r
  32 </client>\r
  33 \r
  34 Each client will have to be identified by a specific name, if a name in the\r
  35 config is not found in the client list, the init should fail. A client can\r
  36 still be hardcoded and not appear in this list though.\r
  37 (a GetName() function to synapse client)\r
  38 \r
  39 SYN_REQUIRE_ANY support will work for strict API lists. Just the same way \r
  40 we do the simple SYN_REQUIRE\r
  41 \r
  42 Discussion:\r
  43 -----------\r
  44 \r
  45 We only deal with SYN_REQUIRE. It is possible that at some point we will want\r
  46 to customize the SYN_PROVIDE too. For instance depending on the game mode, a\r
  47 same module could provide two different minors. Couldn't provide the two minors\r
  48 at the same time though, only one.\r
  49 \r
  50 Implementation:\r
  51 ---------------\r
  52 \r
  53 Default config file will be synapse.config in the gametools path. We can override\r
  54 this later with a custom line in the .game file. Should Synapse be able to operate\r
  55 without this config file though, as it is looked up by the main program and handed\r
  56 over to synapse before init? Possibly .. we'll just pass a NULL config node ptr\r
  57 \r
  58 Add the config file path to CSynpaseServer::Initialize, pass the loaded XML file to\r
  59 the clients. Do we need to wrap in an object with some convenience functions?