* Added the NOTES file, containing some thoughts about the ASYN protocol,

eloquently elaborated upon by AJC (Ig).

diff --git a/libCxClient/ChangeLog b/libCxClient/ChangeLog
index f6e9146d77c8f4c7901904d7624cb8bd67d950e2..0946d4d8b6425aa77c819dfb16c2b9f584357163 100644 (file)
--- a/libCxClient/ChangeLog
+++ b/libCxClient/ChangeLog
@@ -1,7 +1,12 @@
 $Log$
+Revision 1.4  2001/02/14 03:48:51  brian
+* Added the NOTES file, containing some thoughts about the ASYN protocol,
+eloquently elaborated upon by AJC (Ig).
+
 Revision 1.3  2001/02/07 22:42:24  brian
 * Removed ID tag.
 
 Revision 1.2  2001/02/07 22:41:51  brian
 * Updated ChangeLog to conform to Citadel/UX standards (kinda)  :)
 
+

diff --git a/libCxClient/NOTES b/libCxClient/NOTES
new file mode 100644 (file)
index 0000000..85d7966
--- /dev/null
+++ b/libCxClient/NOTES
@@ -0,0 +1,56 @@
+libCxClient - Citadel/UX Extensible Client API
+Copyright (c) 2000, Flaming Sword Productions
+Copyright (c) 2001, The Citadel/UX Consortium
+All Rights Reserved
+
+http://www.shadowcom.net/Software/libCxClient/
+================================================================================
+
+Miscellaneous Notes
+-------------------
+These are some notes which were involved in the development of the asynchronous
+(ASYN) protocol on Citadel/UX.  As I recall, these statements were made by
+Art J. Cancro, Master of Citadel/UX.  It all makes sense to me, though! :)
+
+Ok, I'm making a decision.  Here is the protocol.
+ 
+ At any time between commands, or between the time a client enters a command
+and the reply from that command is generated, the server MAY spit out a
+900 series message.  This is an asynchronous message and the client MUST
+process it immediately.
+ 
+ A 900 series message will always be followed by a 100, 200, 300, 400, 500,
+600, or 700 series message which carries the data of the asynchronous
+message.
+ 
+ I like most of dT's codes, and we'll probably go with something like that.
+I think the actual data of the message should be in the second line rather
+than in the 900 message, though.  For example, if 901 means "express message
+arriving" then...
+ 
+ 
+901 xmsg follows:
+100 0|979362858|0|IGnatius T Foobar|uncnsrd
+This is the text,
+ of the message that is being received,
+  and it is really cool.
+>000
+ 
+ 
+ The benefit of this, in the example above, is that the output is exactly
+the same as the output of the GEXP command.  Opportunities for code sharing
+abound.
+ 
+ 
+ If the client had already sent a command, and it got the 901, it would have
+to handle the 901 and its data transfer first, putting it in a queue if
+necessary, and then receive the output of the command it sent (unless it gets
+another 900 first, in which case it keeps running the appropriate handlers
+until it gets something other than a 900).
+ 
+ 
+ After thinking about it all day, this is the way I'd like to go unless dT
+has a problem with it.
+
+================================================================================
+$Id$