home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / wc40rec.zip / WCMSGDB.DOC < prev    next >
Text File  |  1994-06-01  |  6KB  |  112 lines
  1. Wildcat 4 Message Database Notes
  2. --------------------------------
  3.  
  4. The message database is no longer stored in a Filer database.  There are two
  5. files which make up a message database:
  6.  
  7. MSGn.IX  - contains the message number index
  8. MSGn.DAT - contains the message headers and text
  9.  
  10. The MSGn.IX file is divided into six byte records.  There is one record at
  11. the start of the file as follows:
  12.  
  13. type
  14.   TMsgIndexHeader = record
  15.     RecordSize    : Word;
  16.     ActiveRecords : Word;
  17.     NextMsgNumber : Word;
  18.   end;
  19.  
  20. RecordSize will be set equal to 6.  This is for sanity checking.
  21. ActiveRecords is the number of active (not deleted) messages in the
  22. conference.  NextMsgNumber is the next message number that will be added
  23. to the end of the file (this number must be updated every time you add
  24. a message).
  25.  
  26. The rest of the records in the file are TMsgIndexEntry records:
  27.  
  28. type
  29.   TMsgIndexEntry = record
  30.     MsgNumber    : Word;
  31.     HeaderOffset : Longint;
  32.   end;
  33.  
  34. These records contain, for each message, the message number and byte offset
  35. in the .DAT file of the start of the corresponding message header.
  36.  
  37. The file is organized like this:
  38.  
  39. ofs       MSGn.IX                                 MSGn.DAT
  40.  0+----------------------+       +-------->+----------------------+
  41.   | index file header    |       |         | first message header |
  42.   |                      |       |         +----------------------+
  43.  1+----------------------+       |         |This is the text of   |
  44.   | first message number |       |         |the first message. It |
  45.   | offset to header data--------+         |is stored the same way|
  46.  2+----------------------+                 |it is in memory - with|
  47.   | second message number|                 |a single CR at the end|
  48.   | offset to header data--------+         |of each line (a CR is |
  49.  3+----------------------+       |         |required at the end of|
  50.   |                      |       |         |the last line of the  |
  51.   |                      |       |         |message too).         |
  52.   .                      .       +-------->+----------------------+
  53.   .                      .                 | second message header|
  54.                                            +----------------------+
  55.                                            |Immediately following |
  56.                                            |the previous message  |
  57.                                            |text, the next message|
  58.                                            |header follows.       |
  59.                                            +----------------------+
  60.                                            |                      |
  61.                                            .                      .
  62.  
  63. There is a new field at the start of the message header called MagicNumber.
  64. This field will contain one of these two constants:
  65.  
  66. const
  67.   MagicHeaderActive   = $001A1A1B;
  68.   MagicHeaderInactive = $011A1A1B;
  69.  
  70. Active messages must have MagicHeaderActive in the MagicNumber field, and
  71. inactive messages must have MagicHeaderInactive.  An 'inactive' message is
  72. only created when a message is edited and more text is added to the message
  73. body.  When this happens the message can no longer reside in its original
  74. location, so its old header is marked inactive and the new message header
  75. and text is written at the end of the MSGn.DAT file.  Note that in particular,
  76. deleted messages are NOT marked as inactive.
  77.  
  78. When adding a new message to the database, the message header and text will
  79. simply be appended to the MSGn.DAT file and the offset in the MSGn.IX file
  80. will point to the offset at which the new text was added.
  81.  
  82. Unlike Wildcat 3, there is no longer a Ctrl-Z at the end of the message text.
  83. The end of the message is determined from the MsgBytes field in the message
  84. header.  Each line must be terminated with a CR (including the last line).
  85. Failure to make sure this is exactly right may cause Wildcat or other programs
  86. to not read the messages correctly.
  87.  
  88. The unread messages are stored in a completely new way.  There is a field
  89. in the user database (see WCUSERDB.DOC) called cuFirstUnread.  This is the
  90. message NUMBER (not offset) of the first unread message in the corresponding
  91. conference for the user.  Each message has a PrevUnread and NextUnread field
  92. that holds the message NUMBER of the previous unread message and the next
  93. unread message, respectively, for that user.  This is a doubly linked circular
  94. list, which means that the last unread message's NextUnread points to the first
  95. unread message, and the first unread message's PrevUnread points to the last
  96. unread message.  This is to aid in quickly adding new unread messages to the
  97. end of the database.
  98.  
  99. When messages are read by the recipient, the forward and back links need to
  100. be updated to be consistent with the new state of the unread messages chain.
  101. This process may require modifying up to three message headers plus the
  102. cuFirstUnread field of the user record.
  103.  
  104. When messages are deleted, they are not unhooked from the unread chain.
  105. They just need to have their mfDeleted bit set in the message flags.
  106. Message records are not removed from the file when they are deleted -
  107. this is done by WcRepair or WcPack.
  108.  
  109. Writing and modification file access to the MSGn.IX file or MSGn.DAT file is
  110. controlled through locking the first byte of the MSGn.IX file.  This is best
  111. done with the BTIsamLockRecord and BTIsamUnlockRecord in Filer.
  112.