home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / top2src.zip / NEWCHAT.TXT < prev    next >
Text File  |  1996-09-15  |  3KB  |  54 lines
  1. Character By Character (CBC) Mode Notes
  2.  
  3. A flag in the NODEIDX stores the node's current chat mode, 0 for old-style LBL
  4. chat, 1 for Dual Window chat mode, and 2 for Split-Screen CBC mode.  The
  5. messaging routines use this value to determine how to send the text.
  6.  
  7. CBC text is stored in a new series of temp files called CHR#####.TCH where
  8. ##### is the node number.  The first byte of this file is used simply for
  9. locking, and does not contain any particular information.  All subsequent bytes
  10. contain the text typed up until this point, as typed by the user.
  11.  
  12. Actions and other such messages are translated as normal and the text is dumped
  13. to this file.  Commands and actions will be prefixed with a configurable
  14. special character (defaults are probably / for commands, which is already used
  15. for many commands, and . for actions, which is common in Major) so TOP knows
  16. not to echo them to the other users.
  17.  
  18. The CHR chat file is opened in Binary Append mode for fastest file i/o.  The
  19. first byte is to be locked when the file is in use.  An time-delayed output
  20. buffer will be necessary for smoother operation, based on the performance of
  21. the prototype Private Chat code.  It looks like the best thing to do is to
  22. flush the buffer at configurable intervals, probably 1/3 or 1/2 a second by
  23. default.  It also will probably be helpful to only read the buffer at
  24. configurable intervals, defaulting at 1/5 or 1/4 a second.
  25.  
  26. Once the receiving node reads the file, the size is changed with chsize() to a
  27. size of 1 byte, the file pointer is reset (using SEEK_END), and the first byte
  28. is of course then unlocked.  This allows an added speed advantage by allowing
  29. receiving nodes to simply check filelength <= 1 to know whether or not new text
  30. has arrived.  Both reads and writes are to be preformed at seperate
  31. configurable intervals.  The reads configured by time, and the writes
  32. configured by time but also prematurely performed after reads, whichever event
  33. comes first. This should allow for a smooth flow without bogging down the
  34. system too much.
  35.  
  36. ADDENDUM
  37.  
  38. The CHR*.TCH files will need to contain sending info instead of just text
  39. bytes.  The best way is to provide a three byte header for each write to the
  40. file as follows:
  41.  
  42.  Bytes 0,1 - Sending node.
  43.     Byte 2 - Length of text for this dump.
  44.  
  45.     The text bytes follow for the length given in byte 2.  A fourth byte may be
  46. added to the header if special info. flags are needed, but this will not cause
  47. any backward compatibility problems so it has been left out for now.
  48.  
  49.     Another option would be to assign 256 byte buffer zones for each of the 6
  50. nodes in the file.  This would cause less file sharing conflicts but it would
  51. result in more file accesses, although it would also be faster on screen
  52. because TOP can read one node at a time and not have to jump around to each of
  53. the different windows so much.
  54.