Author: nornagon
Date: 2005-05-21 01:02:59 -0400 (Sat, 21 May 2005)
New Revision: 686
Modified:
trunk/docs/manual/formats.texi
trunk/docs/manual/introduction.texi
trunk/docs/manual/protocol.texi
Log:
A few corrections/additions to the docs.
Modified: trunk/docs/manual/formats.texi
===================================================================
--- trunk/docs/manual/formats.texi 2005-05-21 04:20:47 UTC (rev 685)
+++ trunk/docs/manual/formats.texi 2005-05-21 05:02:59 UTC (rev 686)
@@ -22,22 +22,22 @@
@table @code
@item %Y
-The year, such 2004 or 1985.
+The year in four digits, such 2004 or 1985.
@item %m
-The month, from 01 to 12.
+The month in two digits; from 01 to 12.
@item %d
-The day, from 01 to 31.
+The day in two digits; from 01 to 31.
@item %H
-The hour, from 00 to 23.
+The hour in 24-hour time; from 00 to 23.
@item %M
-The minute, from 00 to 59.
+The minute in two digits, from 00 to 59.
@item %S
-The second, from 00 to 60 (for leap seconds).
+The second in two digits, from 00 to 60 (for leap seconds).
@end table
An example: 2005-03-22 04:10:28.
Modified: trunk/docs/manual/introduction.texi
===================================================================
--- trunk/docs/manual/introduction.texi 2005-05-21 04:20:47 UTC (rev 685)
+++ trunk/docs/manual/introduction.texi 2005-05-21 05:02:59 UTC (rev 686)
@@ -5,9 +5,9 @@
@chapter Introduction
[EMAIL PROTECTED] is a network protocol for real time textual confrencing,
[EMAIL PROTECTED] is a network protocol for real time textual conferencing,
and is being developed by an international coalition of four insane
programmers.
-It does @strong{not} utilize advanced technologies such as XML.
+It does @strong{not} utilize complicated standards such as XML.
It is a simple, line based, tab delimited messaging protocol,
in the same spirit as IRC. However it is not meant as a replacement to IRC,
Jabber, or SILC.
@@ -34,8 +34,8 @@
Haver is (mostly) a client-server protocol.
Thus a server is needed for two haver clients to communicate.
Servers store metadata about each client, and also maintain the list of
channels.
[EMAIL PROTECTED] expand!
-
@node Global Server List
@subsection Global Server List
@@ -46,7 +46,7 @@
@section Clients
A haver client is any TCP/IP program that conforms to the haver protocol.
-There are two varieties of clients: Users and Clients.
+There are two varieties of clients: Users and Services.
Users are representations of either real people, chatbots, or GreenReaper.
@@ -68,8 +68,10 @@
@subsection Lobby
The lobby is like a special channel. It contains all the users, services, and
channels
-of the server.
+of the server. It goes by the name &lobby.
+One can neither join nor part &lobby.
+
@node Entities
@section Entities
Modified: trunk/docs/manual/protocol.texi
===================================================================
--- trunk/docs/manual/protocol.texi 2005-05-21 04:20:47 UTC (rev 685)
+++ trunk/docs/manual/protocol.texi 2005-05-21 05:02:59 UTC (rev 686)
@@ -6,11 +6,12 @@
@chapter Protocol
The haver protocol is relatively easy to parse:
-Simply split lines on the tab character. There is an optional escaping
-mechanism, and support for Unicode. These issues are explained next.
+simply split input by lines (ie, separated by \r\n) on the tab character.
+There is an optional escaping mechanism, and support for Unicode.
+These issues are explained next.
@menu
-* Character codes:: Unicode your friend.
+* Character codes:: Unicode your friends.
* Parsing:: Banana Split.
@end menu
@@ -24,11 +25,11 @@
@node Parsing
@section Parsing
-The protocol is delimited into lines separated by CR LF (0x0D 0x0A).
+The protocol is delimited into lines separated by CR LF (0x0D 0x0A or "\r\n").
Each line is further delimited by the Tab character (0x09) into a series of
tokens.
The first of the tokens is called the command.
The remaining tokens (if any) are refered to as the arguments.
-The command and arguments together make up the message.
+The command and arguments together make up a message.
If a literal tab, carriage return, or line feed needs to be sent,
it must be written in escaped form with the Esc character (0x1b).
@@ -41,5 +42,3 @@
Currently there is no defined behavior for ASCII NUL characters in the
protocol.
Comments and suggestions on how to deal with them is welcome.
-
-
