|
|
1.1 ! root 1: Brian, ! 2: ! 3: Here are the differences I see between your and my server. ! 4: I've included proposed changes, some to yours, some to mine. If ! 5: we could get agreed on a standard by this weekend, which may be ! 6: ambitious, it would be really good. ! 7: ! 8: BTW, is the stuff I'm ">" including the current version? ! 9: ! 10: Phil ! 11: ! 12: ! 13: > The whole idea is to keep the server as small and (computationally) ! 14: > inexpensive as possible. Reading news on our system is not a super ! 15: > popular pastime, but a central machine could still get rather heavily ! 16: > loaded if 5 people per system were to decide that it was time to catch ! 17: > up on the latest happenings. ! 18: ! 19: Agreed. This is, I feel, an implementation detail, although it ! 20: should be reflected in the protcol -- i.e., the protocol should ! 21: not be bulky or hard to implement. I don't think we suffer from ! 22: this problem. ! 23: ! 24: > No doubt I'll refine it further as I try to interface more client stuff ! 25: > to it. Right now it seems to have enough to start making a version of ! 26: > 'readnews' work with it. ! 27: ! 28: This is a matter of philosophy: I feel it's very important to make the ! 29: server as easy to interface with existing programs as possible, but ! 30: still be general enough to provide for future service. ! 31: ! 32: General differences: Let's try to make this as SMTP-like as ! 33: possible. One thing I noticed is that you put "."'s in front of ! 34: your reply codes. SMTP doesn't do this, and I can't think of ! 35: why you do it. Am I missing something? ! 36: ! 37: As far as variable length messages go, there are two possibilities: ! 38: The one I am using currently is the ! 39: ! 40: xxx-Start of text, look out /* assumed to be one line */ ! 41: xxx-blah blah ! 42: xxx-blah blah ! 43: xxx-blah blah ! 44: xxx-blah blah ! 45: xxx end of text (no dash) ! 46: ! 47: I don't really like this, since it means we strip off four characters per ! 48: line, which slows things down that much. ! 49: ! 50: The second possibility is that we say ! 51: ! 52: xxx-Start of text, look out /* again, a one liner */ ! 53: Text goes ! 54: here, ! 55: with a period on a ! 56: line by itself, just ! 57: like SMTP. ! 58: . ! 59: xxx End of text /* Maybe we don't need this message */ ! 60: ! 61: As usual, any line in the message which starts with a period we ! 62: simply duplicate -- that it, we put an extra period in front, ! 63: and then the client strips it off. If there is only one period, ! 64: it must be EOF. ! 65: ! 66: How say you to this? ! 67: ! 68: > Commands consist of an UPPERCASE command word, some of ! 69: > which are followed by parameters. All input is in ASCII, ! 70: > terminated in CR-LF. ! 71: ! 72: Very much agreed, especially the CF-LF stuff. It's fairly ! 73: trivial to accept lower case, I think you already have hacked ! 74: your daemon to do this. But the std should probably call for ! 75: upper case. ! 76: ! 77: > BODY No parameters. Displays the body (text) of the ! 78: > current article. ! 79: ! 80: Same here, except we differ on arguments. All of my commands ! 81: like BODY, HEADER, etc. require an article number as an argument. ! 82: I think this is better because it's more what readnews/rn will ! 83: want: They have an "open article" function, with a numeric ! 84: argument. I don't think we need the "next" function, since it ! 85: hides the article numbers from the client, and the client, if ! 86: it is an existing program, will want to worry about article numbers. ! 87: ! 88: > GET nnn (nnn) is the numeric id of an article in the ! 89: > current newsgroup. It must be chosen from the ! 90: > range of articles provided when the newsgroup was ! 91: > selected. ! 92: ! 93: This is my "ARTICLE" command. ! 94: ! 95: > GROUP ggg (ggg) is the name of the newsgroup to be selected. ! 96: ! 97: Same here. ! 98: ! 99: > HEAD No parameters. Displays the header lines of the ! 100: > current article. ! 101: ! 102: Same here, but with parameters. ! 103: ! 104: > LAST No parameters. Backs up to the previous article ! 105: > in the current newsgroup. If already positioned ! 106: > at the beginning of the newsgroup, an error ! 107: > results. ! 108: ! 109: No equivalent here. Do we need this? Again, rn/readnews will ! 110: take care of this internally. ! 111: ! 112: > NEXT No parameters. Advances to the next article in ! 113: > the current newsgroup. If no more articles remain ! 114: > in the current group, an error results. ! 115: ! 116: Same comment as for LAST. ! 117: ! 118: > QUIT No parameters. The server process exits and ! 119: > closes the connection to the client. ! 120: ! 121: Great minds think alike. ! 122: ! 123: Some commands I didn't see in yours: ! 124: ! 125: ACTIVE - transmit the active file in normal format. By normal, ! 126: I mean normal, 4.2 UNIX active file format. ! 127: ! 128: POST - User sends an article, followed by a period on a line ! 129: by itself. This is passed to inews, which deals with ! 130: it. After inews has dealt with it, daemon returns ! 131: a reply code. ! 132: ! 133: NEWSINCE "date" List the new articles, since "date", where ! 134: date is a long integer containing the number of seconds ! 135: since Jan 1, 1970. Should this be GMT? ! 136: ! 137: BOUNDS - Show high and low message number in current newsgroup. ! 138: You provide this with your "GROUP" command, and I should ! 139: too. ! 140: ! 141: > Responses are of two kinds. Command/status responses ! 142: > are distinguished by having a single period (.) as the first ! 143: > character of the line. Text lines have no period, or if the ! 144: > text contained a period in the original, that period is dou- ! 145: > bled. The intention is that text messages will be displayed ! 146: > directly on the user's terminal (or processed through ! 147: > 'more'), whereas command/status responses will be inter- ! 148: > preted by the client program before any possible display is ! 149: > done. ! 150: ! 151: As I said above, I move we go to this sort of thing, but ! 152: have a single period, so as to be like SMTP. I love conformity. ! 153: ! 154: > Response codes are returned in a command/status return ! 155: > line (i.e., they are prefixed with a period). These are ! 156: > status reports or command responses from the daemon and ! 157: > indicate the response to the last command received from the ! 158: > client. ! 159: ! 160: You have your status messages much more thought out than I ! 161: do, since I sort of assigned them randomly/sequentially. ! 162: Also, has it been your experience that only 200/500 series gets used? ! 163: ! 164: > 1xx Informative messages - no significance except to ! 165: > humans. Probably these should be displayed to the ! 166: > user. ! 167: > ! 168: > 2xx Last command was ok and is being performed. Mostly ! 169: > just indicate that you asked the daemon to do something ! 170: > reasonable and it did it. ! 171: > ! 172: > 3xx Continue with the command. (used on commands that ! 173: > expect to receive more data) You should then send the ! 174: > rest of the data. ! 175: > ! 176: > 4xx Couldn't do your last command. Perhaps you simply ! 177: > specified a non-existing article or something. ! 178: > ! 179: > 5xx Couldn't do your last command. Serious error - the ! 180: > command was invalid, or was missing parameters, or the ! 181: > daemon program faulted. This means that something was ! 182: > wrong enough with your command that current status is ! 183: > in doubt. Perhaps one or more pointers has been ! 184: > changed. Don't proceed until you have re-established ! 185: > the environment (newgroup/article selection). (An ! 186: > exception is the "500 bad command" response - your ! 187: > entire command was flushed and ignored.) ! 188: > ! 189: > The next digit in the code indicates the function response ! 190: > category. ! 191: > ! 192: > x0x Client setup and miscellaneous messages ! 193: > ! 194: > x1x Newsgroup selection ! 195: > ! 196: > x2x Article selection ! 197: > ! 198: > x3x Article display ! 199: > ! 200: > x4x <reserved> ! 201: > ! 202: > x5x Posting ! 203: > ! 204: > ! 205: > ! 206: > The following response codes are to be expected. ! 207: ! 208: Following SMTP, it should be possible to write a "dumb" client which ! 209: doesn't look for a "211", but rather, a "2" in response to a ! 210: "GROUP" command, and it knows what order the arguments are in. ! 211: ! 212: > 200 news server ready ! 213: > 201 news server closing connection ! 214: > 211 %d %d %d %s ! 215: > (number of articles in group, ! 216: > first article number in the group, ! 217: > last article number in the group, ! 218: > name of the group. ! 219: > 215 active start ! 220: > 216 active end ! 221: > 221 %d %d %d %d %s article retrieved ! 222: > (article number, ! 223: > first article number in the group, ! 224: > last article number in the group, ! 225: > unique article id (usually the inode number) ! 226: > 230 head start ! 227: > 231 head end ! 228: > 235 body start ! 229: > 236 body end ! 230: > 250 article posted ok ! 231: > 354 send article to be posted. End with <CRLF>.<CRLF> ! 232: > 411 no such news group ! 233: > 412 empty newsgroup ! 234: > 413 more than MAXART articles; others suppressed ! 235: > 415 no active file ! 236: > 421 No next article in this group ! 237: > 422 No previous article in this group ! 238: > 422 no such article number in this group ! 239: > 431 no file ! 240: > 432 no file ! 241: > 500 bad command ! 242: > 521 article file missing ! 243: > 522 article file missing - unable to stat ! 244: > 550 can't start inews for posting ! 245: >
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.