libcitadel/hash_todo.txt

   1 This file is for notes on converting things to use the hash functions Dothebart added.
   2
   3
   4 Convert the server config to use these functions.
   5 Alter citserver to read key value pairs for the config instead of an ordered file.
   6 Alter citserver to store the config in the data base.
   7 Add code to serv_upgrade to convert the current file into a normal message in the DB.
   8 serv_upgrade will read the file create at setup time on first boot to get it into
   9 the DB this way the existing setup tools don't need to be altered.
  10
  11 Webcit can then ask for the site wide config using normal MSG* commands.
  12 Webcit will need to parse the message into key value pairs which is dead simple to do.
  13
  14 Hmm, just a thought but has anyone wondered about locking things like this so 2 Aides can't
  15 change them at the same time which would result in some changes getting lost.
  16
  17
  18
  19 We can use this code for any key value pair situation since the has should be faster than sequential search.
  20 Possible candidates are.
  21
  22
  23 get_user and friends.
  24 Load the user list into the hash at boot.
  25 Write new entries to the DB when the occur.
  26 Use 2 hashes so we can quickly get user by name or number. This might be possible since
  27 the hash value can be any object. user name hash is master and sync'd wuth DB and has real destructor,
  28 user number hash uses exact same user object but dummy destructor that does nothing. That way
  29 destructing a key from the hash has expected results. Destructor could also call purge_user maybe?
  30 Perhaps delay writing changes if the server is busy.
  31 This would save on DB accesses which can be a bottle neck.
  32 Definately would save on DB reads.
  33
  34
  35 netconfigs??
  36
  37
  38 mail.aliases
  39 Load into a hash at startup and done with?
  40 Perhaps even bring this into the DB as a MSG update the MSG if the file changes for backward compat. Then
  41 we can make it changeable via client. File gets out of date though.
  42 Read from the DB as needed, cache into the hash?
  43
  44
  45 Webcit URL's
  46 Some of these might benefit from a hash.
  47 bstr does a sequential search for the key so a hash would be faster in cases where the URL contains lots of
  48 stuff like site config and probably more.
  49
  50
  51 Since the hash can store arbitrary objects we can probably use it to store contexts and threads.
  52 At first this seems as though it won't do much for performance but done right I think we will be
  53 able to do away with the locking of the entire list and reduce the granularity to locking only the context/thread struct
  54 we are currently working on.
  55 Perhaps a modified hash that locks the retrieved entry and unlocks the entry by a call to unlock key.