]> code.citadel.org Git - citadel.git/blobdiff - citadel/techdoc/session.txt
* Augmented the "headers only" functionality of the message reading API (as
[citadel.git] / citadel / techdoc / session.txt
index 24dcd739ce33fbfb598094589fd14ce0f7174f56..ad0629daa14d6c6c0720ff699b140e8425023291 100644 (file)
@@ -357,6 +357,12 @@ it completes.  For passworded rooms, access will be denied if the password
 is not supplied or is incorrect, or the command will complete successfully
 if the password is correct.
  
+ The third (and also) optional parameter is a "transient" flag.  Normally,
+when a user enters a private and/or zapped room, the room is added to the
+user's known rooms list.  If the transient flag is set to non-zero, this is
+called a "transient goto" which causes the user to enter the room without
+adding the room to the known rooms list.
  The possible result codes are:
   
  OK    - The command completed successfully.  User is now in the room.
@@ -477,15 +483,12 @@ criteria.  These criteria are applied with an AND logic.
  This is a command used to read the text of a message.  "Mode 0" implies that
 other MSG commands (MSG1, MSG2, etc.) will probably be added later on to read
 messages in more robust formats.  This command should be passed two arguments.
-The first is the message number of the message being requested.  In server 
-version 4.04 and above, the second argument may be set to either 0 to read the
-entire message, or 1 to read the headers only.
- The server should, of course, make sure that the client actually has access
-to the message being requested before honoring this request.  Citadel/UX does
-so by checking the message number against the contents of the current room.  If
-it's not there, the request is denied.
+The first is the message number of the message being requested.  The second
+argument specifies whether the client wants headers and/or message body:
+ 0 = Headers and body
+ 1 = Headers only
+ 2 = Body only
+   
  If the request is denied, an ERROR code will be returned.  Otherwise, the
 LISTING_FOLLOWS code will be returned, followed by the contents of the message.
 The following fields may be sent:
@@ -514,6 +517,14 @@ seconds since midnight on January 1, 1970, GMT).
  node=   The short node name of the system this message originated on.
  hnod=   The long node name of the system this message originated on.
  zaps=   The id/node of a message which this one zaps (supersedes).
+
+ part=   Information about a MIME part embedded in this message.
+ pref=   Information about a multipart MIME prefix such as "multipart/mixed"
+         or "multipart/alternative".  This will be output immediately prior
+         to the various "part=" lines which make up the multipart section.
+ suff=   Information about a multipart MIME suffix.  This will be output
+         immediately following the various "part=" lines which make up the
+         multipart section.
  
  text    Note that there is no "=" after the word "text".  This string
 signifies that the message text begins on the next line.
@@ -835,6 +846,7 @@ or ERROR or ERROR+HIGHER_ACCESS_REQUIRED if the command will not succeed.
        3  -  Private; invitation only (sometimes called "exclusive")
  3  -  Password for new room (if it is a type 2 room)
  4  -  Floor number on which the room should reside (optional)
+ 5  -  Set to 1 to avoid automatically gaining access to the created room.
  
  If the create flag is set to 1, the room is created (unless something
 went wrong and an ERROR return is sent), and the server returns OK, but
@@ -1736,12 +1748,31 @@ into the system.  It is implemented in the serv_expire module.
  
   
  
- MSG4   (read MeSsaGe, mode 4 -- enumerate MIME parts)
+ MSG4   (read MeSsaGe, mode 4 -- output in preferred MIME format)
  
-     FIXME ... do the writeup for this once it's done.
+ This is the equivalent of MSG0, except it's a bit smarter about messages in
+rich text formats.  Immediately following the "text" directive, the server
+will output RFC822-like MIME part headers such as "Content-type:" and
+"Content-length:".  MIME formats are chosen and/or converted based on the
+client's preferred format settings, which are set using the MSGP command,
+described below.
+  
  
-
+ MSGP   (set MeSsaGe Preferred MIME format)
+ Client tells the server what MIME content types it knows how to handle, and
+the order in which it prefers them.  This is similar to an HTTP "Accept:"
+header.
+ The parameters to a MSGP command are the client's acceptable MIME content
+types, in the order it prefers them (from most preferred to least preferred).
+For example:  MSGP text/html|text/plain
+ The MSGP command always returns OK.
+  
   
+   
  OPNA   (OPeN Attachment)
  
  Opens, as a download file, a component of a MIME-encoded message.  The two