home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / TIERRA40.ZIP / ALMOND / ALCOMM / SRC / TODO < prev    next >
Text File  |  1992-07-06  |  2KB  |  39 lines
  1.  
  2.    need some way of breaking out of the waiting state when waiting for a reply
  3.    if for some reason the reply doesn't happen... is there any possibility of
  4.    this at all??  I don't *think* so, but verify.
  5.      |
  6.      \---> this should have been fixed by requiring the query handler to
  7.        call MGenReply.  if it doesn't, the mlayer issues a bogus (error)
  8.        reply which satisfies the blocking end, so there should never be
  9.        a problem.
  10.  
  11. MAY WANT TO PROVIDE a function to do messages, to do queries, etc... so that
  12. the user doesn't have to use MGenRequest and MGenRequestWithReply and get
  13. himself into trouble!  Think about it - it's just a few lines!
  14.  
  15. use MrERROR to signal out-of-range messages, queries, etc.
  16.  
  17. when enabling a new dataflow, should we automatically call the Initialise
  18. procedure (if one is registered) from within MDataflowControl(), or should
  19. we enter a request in the queue and deal with it separately?
  20.   |
  21.   \---> right now, it's handled inside MDataflowControl().
  22.  
  23. look over AL and M layers wherever handles are used; make sure there's enough
  24. verification for valid handles... don't want to crash something.
  25.  
  26. wherever status return values are used, make sure variable holding them
  27. has value either ALtStatus or MtStatus (depending on package)
  28.  
  29. =============================================================================
  30.  
  31. tierra-end TODO:
  32.  
  33. replace instances of ALGripe in tierra with whatever error reporting
  34. scheme is to be used.
  35.  
  36. provide a mechanism for rerouting errors (but still through ALGripe) wherever
  37. user code requires - alerror.c will have to change slightly.  maybe a
  38. callback-type approach would work?
  39.