libCxClient/NOTES

   1 libCxClient - Citadel/UX Extensible Client API
   2 Copyright (c) 2000, Flaming Sword Productions
   3 Copyright (c) 2001, The Citadel/UX Consortium
   4 All Rights Reserved
   5
   6 http://www.shadowcom.net/Software/libCxClient/
   7 ================================================================================
   8
   9 Miscellaneous Notes
  10 -------------------
  11 These are some notes which were involved in the development of the asynchronous
  12 (ASYN) protocol on Citadel/UX.  As I recall, these statements were made by
  13 Art J. Cancro, Master of Citadel/UX.  It all makes sense to me, though! :)
  14
  15 Ok, I'm making a decision.  Here is the protocol.
  16
  17  At any time between commands, or between the time a client enters a command
  18 and the reply from that command is generated, the server MAY spit out a
  19 900 series message.  This is an asynchronous message and the client MUST
  20 process it immediately.
  21
  22  A 900 series message will always be followed by a 100, 200, 300, 400, 500,
  23 600, or 700 series message which carries the data of the asynchronous
  24 message.
  25
  26  I like most of dT's codes, and we'll probably go with something like that.
  27 I think the actual data of the message should be in the second line rather
  28 than in the 900 message, though.  For example, if 901 means "express message
  29 arriving" then...
  30
  31
  32 901 xmsg follows:
  33 100 0|979362858|0|IGnatius T Foobar|uncnsrd
  34 This is the text,
  35  of the message that is being received,
  36   and it is really cool.
  37 >000
  38
  39
  40  The benefit of this, in the example above, is that the output is exactly
  41 the same as the output of the GEXP command.  Opportunities for code sharing
  42 abound.
  43
  44
  45  If the client had already sent a command, and it got the 901, it would have
  46 to handle the 901 and its data transfer first, putting it in a queue if
  47 necessary, and then receive the output of the command it sent (unless it gets
  48 another 900 first, in which case it keeps running the appropriate handlers
  49 until it gets something other than a 900).
  50
  51
  52  After thinking about it all day, this is the way I'd like to go unless dT
  53 has a problem with it.
  54
  55 ================================================================================
  56 $Id$