[550] in Zephyr_Comments
daemon@ATHENA.MIT.EDU (James D. Zelenka)
Wed May 27 16:04:27 1992
Date: Wed, 27 May 1992 16:02:44 -0400 (EDT)
From: "James D. Zelenka" <jz1j+@andrew.cmu.edu>
To: zephyr-comments@Athena.MIT.EDU
Excerpts from mail: 27-May-92 Re: ping Marc Horowitz@Athena.MIT (125)
> Well, you can try asking your question here. The worst that will
> happen is you will continue to get no response :-)
OK :-).
After writing a few clients, I have a couple suggestions about ways to
clean up the libraries to make it easier for potential zephyr developers.
One is to move the signature out of the message body and give it its own
field in the ZNotice structure. IMO, no special fields or information
that are used by more than one client (in this case, zwrite and zwgc,
and other clients which wish to send or receive zephyrgrams in some way
compatible with these clients) should have to be parsed by the client
when assembling or disassembling the message. I realize that this is a
fairly major change, since it would not be backwards-compatible with
older versions of zwrite, zwgc, and other clients which send and receive
zephyrgrams, but I think it would be worth it, considering how much
easier it would make things for new developers.
I also noticed that tabs and newlines must be handled specially (namely,
tabs are mapped to spaces, and newlines to/from NULLs) when sending and
receiving. Any chance a function could be included to format ascii
message bodies in this fashion? Additionally, howabout a function
something like:
int ZSendAscii(char *recipient, char *body, char *opcode, char *class,
char *instance);
or something? The return value would be one of your predefined error
codes, and the meaning of the parameters should be obvious :-). Then,
zwrite would simply be a front-end to this function. The reason I
suggest this is that I find myself copying a function like this every
time I write a new client which wishes to send messages in a manner such
that they can be read and understood by zwgc.
Also, is there any estimate on when the next release will be?
One more thing... I notice that some functions in libzephyr want to take
a port number to use, while others use the port number kept statically
within the library. I have no problem with either passing this value in
consistently, or having it be read from a static variable within the
library, but the inconsistency is disturbing since it implies that I
could try to use more than one port within a client, when there may be
some low-level function which will use the wrong port at some critical
point.
BTW, zephyr is a great system... very popular here at CMU both andrew-
and cs-side.
Any chance a contrib section could be included in the next zephyr
release? I'd be interested in seeing what other sites have been using it
for...
-jim
jimz@cs.cmu.edu
jz1j@andrew.cmu.edu
