home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ST-Computer Leser 2002 January
/
STC_CD_01_2002.iso
/
APP
/
CAT505
/
DOC
/
NEWPROTO.TXT
< prev
Wrap
Text File
|
2000-10-30
|
11KB
|
318 lines
Neues Protokoll für CAT
***********************
In CAT 3.0 gibt es ein neues Protokoll, um Informationen zur gerade
angezeigten Nachricht abzufragen.
Basisnachricht:
0x8003
Aufbau:
msgbuf[0] = 0x8003; (* Message-ID *)
msgbuf[1] = apId; (* CAT bzw. Kommunikationspartner, Absender halt *)
msgbuf[2] = 0; (* Oversize, immer 0 *)
msgbuf[3] = sub-opcode;
msgbuf[4+5] = Länge des Buffers;
msgbuf[6+7] = Adresse des Buffers;
Die Kommunikation läuft hauptsächlich unidirectional ab, d.h. eine
Applikation fordert etwas an und CAT antwortet. Nur sehr wenige Nachrichten
werden von CAT unaufgefordert verschickt.
Prinzipiell läuft es so: Die Applikation möchte etwas wissen und fragt bei
CAT nach. Dazu übergibt es einen Buffer und die Länge dieses Buffers. CAT
kopiert die gewünschte Information in den Buffer. Da man teilweise auch
variabel lange Daten abfragen möchte, gibt es folgende Möglichkeit: Das ACC
fragt mit Bufferlänge 0 an und erhält als Antwort in der Bufferlänge die
notwendige Länge des Buffers, um die gewünschte Information aufnehmen zu
können. Da die Länge, die CAT zurückliefert, die reine Länge der Daten ist,
sollte man noch ein Byte für das anhängenden Nullzeichen als Stringabschlu₧
hinzurechnen. Bei einer Länge von 0 ist die Information nicht verfügbar.
Man kann sie trotzdem abfragen, erhält aber halt einen leeren String
zurück. Nach der Längenabfrage kann die andere Applikation mit einem
passend allozierten Buffer nochmal anfragen. Der Buffer mu₧ unter Systemen
mit memory protection von CAT beschreibbar sein. CAT selber stellt keinen
Buffer dafür zur Verfügung.
Sollte der übergebene Buffer für die Daten nicht ausreichen, so gibt CAT
keinerlei Daten zurück, sondern liefert eine ERROR-Antwort zurück.
Dieses Protokoll sollte auch für andere Frontends (namentlich: THE_DOT)
implementierbar sein, da auch eine Teilimplementation mit den notwendigen
Funktionen z.B. für CATalog möglich ist. Dafür reicht es, die An- und
Abmeldung zu implementieren und die Abfragen für Name, Betreff und Gruppe.
Alle Werte bis auf die apId sind übrigens unsigned!
Folgende Sub-Opcodes sind definiert:
00: ACKNOWLEDGE (kein Buffer)
01: ERROR (kein Buffer)
02: Anmeldung bei CAT
03: Abmeldung bei CAT
04: Abfrage Absender
05: Abfrage Realname
06: Abfrage Empfänger
07: Abfrage MsgId (#-Zeile)
08: Abfrage lange MsgId (I-Zeile)
09: Abfrage '-'-Zeile
10: Abfrage Ref-Id (R-Zeile)
11: Abfrage Stichwort
12: Abfrage Organization (O-Zeile)
13: Abfrage Gateway (Y-Zeile)
14: Abfrage Distribution (D-Zeile)
15: Abfrage Mime (M-Zeile)
16: Abfrage Status persönliche Nachricht
17: Abfrage Followup-To (F-Zeile)
18: Abfrage Reply-To
19: Abfrage Message-Text
20: Abfrage Message-Datum
21: Abfrage Status-Datum
22: Abfrage Gruppe
23: Abfrage Originaltext, wie in Datenbank gespeichert
24: Abfrage eigene Nachricht
25: Abfrage eindeutige Id
26: Abfrage Absender aus Sender-Zeile
27: Abfrage Absendername im Fenster
28: Abfrage voller Message-Text
100: Neue Nachricht in Fenster (CAT => ACC)
101: CAT wird beendet
Weitere Sub-Opcodes werden bei Bedarf eingeführt.
Einige Sub-Opcodes sind zwar definiert und werden von CAT auch bearbeitet,
aber da die Daten nicht vorhanden sind, wird immer 0 als Länge
zurückgegeben und keine Daten. Dies betrifft insbesondere Followup-To und
teilweise ReplyTo.
Im folgenden werden die Sub-opcodes etwas genauer beschrieben:
00: ACKNOWLEDGE
Das ist die Antwort von CAT auf die An-/Abmeldung vom ACC, wenn diese
geklappt hat. Ansonsten bekommt das ACC ERROR zurück. msgbuf[4-7] sind 0,
da kein Buffer übergeben wird.
01: ERROR
Das ist die Antwort von CAT auf die An-/Abmeldung vom ACC, wenn diese nicht
geklappt hat. Dürfte nur bei extremen Speichermangel passieren. Au₧erdem
wird ERROR bei jeder nicht implementierten Funktion zurückgegeben.
msgBuf[4] enthält den sub-opcode, der zu dem Fehler führte. msgbuf[5-7]
sind 0.
02: Anmeldung bei CAT
Dies schickt ein ACC an CAT zur Anmeldung. Damit wird es über
Nachrichtenwechsel automatisch informiert und kann die Informationen dann
von CAT abfragen. msgbuf[4-7] sind 0, da kein Buffer übergeben wird.
03: Abmeldung bei CAT
Damit meldet sich ein ACC wieder bei CAT ab. Das ACC wird aus der Liste der
beteiligten Empfänger ausgetragen und erhält als Antwort ein ACKNOWLEDGE.
msgbuf[4-7] sind 0, da kein Buffer übergeben wird.
Die folgenden Funktionen sind alles Abfrage-Funktionen, die ein Element
einer Nachricht abfragen können. Bei allen Elementen ist es möglich, das
CAT nichts zurückliefert. In dem Fall wird in dem Buffer einfach ein leerer
String zurückgegeben. Wenn nur die Länge abgefragt wird durch eine
übergebene Bufferlängee von 0, gibt CAT auch eine 0 als Länge zurück. Die
Antwort besteht immer aus der gleichen Nachricht wie die Anfrage.
04: Abfrage Absender
Absender der Nachricht, falls vorhanden (Mailadresse).
05: Abfrage Realname
Realname des Absenders, falls vorhanden.
06: Abfrage Empfänger
Empfänger der Nachricht, falls vorhanden (meistens nur bei PMs)
07: Abfrage MsgId (#-Zeile)
Message-Id aus der #-Zeile, ist immer vorhanden
08: Abfrage lange MsgId (I-Zeile)
Lange Message-Id, meistens vorhanden
09: Abfrage '-'-Zeile
Verkettung nach oben
10: Abfrage Ref-Id (R-Zeile)
Verkettung über lange Id
11: Abfrage Stichwort
Stichwort der Nachricht, kann auch leer sein.
12: Abfrage Organization (O-Zeile)
O-Zeile aus Outfile
13: Abfrage Gateway (Y-Zeile)
Y-Zeile aus Outfile
14: Abfrage Distribution (D-Zeile)
D-Zeile aus Outfile. Inhalt: K, L, M, N: Keine, Lokal, MausNet, Net
15: Abfrage Mime (M-Zeile)
Inhalt der M-Zeile. Eventuelle Fortsetzung im Text wird nicht
zurückgegeben.
16: Abfrage Status persönliche Nachricht
Nur bei PMs vorhanden, sondern wird nichts zurückgeliefert.
17: Abfrage Follow-Up To (F-Zeile)
Wird zurückgegeben, wenn es im Outfile vorhanden war, also momentan noch
gar nicht. Au₧erdem kann CAT es noch nicht. Daher liefert das immer einen
leeren String.
18: Abfrage Reply-To
Wird zurückgegeben, wenn es im Outfile vorhanden war, also momentan noch
gar nicht. Au₧erdem kann CAT es noch nicht. Daher liefert das immer einen
leeren String.
19: Abfrage Message-Text
Liefert den gesamten Text der Nachricht zurück, wie er in der Datenbank
gespeichert ist. Länge ist theoretisch nicht begrenzt, praktisch momentan
auf 64 KB. Es wird von CAT momentan der Text zurückgegeben, wie er an den
Editor übergeben wurde. Eventuelle Filterungen von MIME-Opcodes sind dort
schon durchgeführt worden und der Text wurde noch nicht umbrochen, d.h. es
können lange Zeilen vorkommen. Der Text wird im internen Format von CAT
übergeben, d.h. als Zeilenende dient ein einzelnes LF.
20: Abfrage Message-Datum
Liefert Erstellungsdatum der Nachricht im GEMDOS-Format zurück. Im ersten
Wort im Buffer das Datum, im zweiten die Zeit. Theoretisch könnte man das
auch komplett in den Messagebuffer packen und mü₧te nicht einen
Speicherblock übergeben, aber zur Vereinheitlichung der Implementation wird
auch hier der übergebene Speicherblock benutzt.
21: Abfrage Statusdatum
Liefert Statusdatum der persönlichen Nachricht im GEMDOS-Format zurück.
Wenn es keine PM ist, wird nur 0 als Zeit und Datum zurückgeliefert.
Ansonsten gilt das gleiche wie bei 20.
22: Abfrage Gruppe
Liefert den Namen der aktuellen Gruppe.
23: Abfrage Originaltext
Liefert den gesamten Text der Nachricht zurück, wie er in der Datenbank
gespeichert ist. Länge ist theoretisch nicht begrenzt, praktisch momentan
auf 64 KB. Es wird von CAT der Text zurückgegeben, wie er in der Datenbank
gespeichert wurde, d.h. es wurden keine Filterungen durchgeführt, keine
Infozeilen in den Text eingeblendet etc. Der Text wird im internen Format
von CAT übergeben, d.h. als Zeilenende dient ein einzelnes LF.
24: Abfrage eigene Nachricht
Fragt nach, ob im Fenster eine eigene Nachricht dargestellt wird. Liefert
nur in der persönlichen Gruppe bei eigenen Nachrichten TRUE zurück. Im
Buffer wird ein Wort übergeben, das 1 ist für eine eigene persönliche
Nachricht, und sonst 0. Weitere Werte werden nicht zurückgeliefert.
25: Abfrage eindeutige Id
Fragt nach einer eindeutigen ID pro Nachricht. Gibt einen unsigned long
zurück, der die Nachricht innerhalb eines CAT-Laufes innerhalb einer
Datenbank eindeutig identifiziert.
26: Abfrage Absender aus Sender-Zeile
Liefert den Absender zurück, wie er in der Sender-Zeile (S-Zeile) im
Outfile kam
27: Abfrage Absendername im Fenster
Liefert den Namen zurück, den CAT im Fenster anzeigt. Bei eigenen
persönlichen Nachrichten ist das der des Empfängers, sonst der des
Absenders.
28: Abfrage voller Messagetext
Wie 19: Abfrage Message-Text, aber ew wird immer der volle Message-Text
zurückgeliefert also incl. Header egal ob diese gerade angezeigt wird
oder nicht.
Die folgende Nachricht wird nur von CAT an die angemeldeten Applikationen
verschickt, und zwar jedesmal, wenn im obersten Anzeigefenster eine neue
Nachricht dargestellt wird. Die Nachricht wird auch verschickt, wenn ein
Anzeigefenster nur getoppt wird.
100: Neue Nachricht in Fenster
msgbuf[4-7] sind 0, da kein Buffer übergeben wird.
Die folgende Nachricht wird nur von CAT an die angemeldeten Applikationen
verschickt, und zwar jedesmal, wenn CAT beendet wird.
101: CAT wird beendet
Wird verschickt, wenn CAT beendet wird. msgbuf[4-7] sind 0.
Hier noch die Definition der einzelnen Nachrichten, wie sie in CAT
implementiert ist:
CONST
CatProtoMsg = 8003H; (* Neues CAT-Protokoll *)
(* Sub-Opcodes für neues CAT-Protokoll *)
(* Doku: Siehe NEWPROTO.TXT *)
CAT_ACK = 0;
CAT_ERROR = 1;
CAT_LOGIN = 2;
CAT_LOGOFF = 3;
CAT_SENDER = 4;
CAT_RNAME = 5;
CAT_RECEIVER = 6;
CAT_MAUS_ID = 7;
CAT_MSG_ID = 8;
CAT_MAUS_REF = 9;
CAT_REF = 10;
CAT_TOPIC = 11;
CAT_BOX = 12;
CAT_GATE = 13;
CAT_DIST = 14;
CAT_MIME = 15;
CAT_STATUS = 16;
CAT_FOLLOWUP = 17;
CAT_REPLYTO = 18;
CAT_TEXT = 19;
CAT_MSG_DATE = 20;
CAT_STATUS_DATE = 21;
CAT_GROUP = 22;
CAT_ORG_TEXT = 23;
CAT_IS_OWN = 24;
CAT_UNIQUE_ID = 25;
CAT_REAL_SENDER = 26;
CAT_WDW_NAME = 27;
CAT_FTEXT = 28; ab CAT 4.18
CAT_NEW_MSG = 100;
CAT_TERMINATE = 101;