Hi John,

You are raising good questions. 

You could indeed return structures (although you will have to look in
coda-src/vicedep how to define the prototypes perhaps).   I'd like to
have a little discussion about this with you to avoid having an
explosion of new structures -- in principle, I think I made a naive
remark about returning stuff in text format. 

The error codes can be transmitted as real Unix error codes and are
translated into an RPC2 independent error.  You simply return the
appropriate error code from the RPC call in the server -- the error
codes which we currently translate are in coda-src/rpc2/errordb.txt.
So don't pass text for errors -- let the client print decent messages
when it receives errors (like EPERM).

The relation between these errors and RPC2 status information lies in
the sign.  If the error is negative, it is an RPC2 error, which is
automatically generated (i.e. I don't think you would have to write
code to pass status information).  If the error is positive, it is an
error returned by the server for the client's interpretation.   So in
the example you mention, the RPC2 could simply return ENOENT.

I hope this is helpful.  What has your group accomplished so far?

- Peter -

John Richter writes:
 > I have come up with a question regarding your original spec for the Yale
 > Protection Server. In the spec it states that information from the server
 > should be returned "using a text buffer." However, when I began to write
 > the detailed interface between the client and server, it occurred to me
 > that if we return data to the client in the appropriate native type, it
 > would be much easier to write different, flexible clients in the future.
 > For example, when the RPC2 function YPS_Examine() was called, if it
 > returned a structure containing fields for the entry name, id, etc. rather
 > than a simple text stream that contained that information, that data could
 > be displayed in a number of different ways by a client. Is there some
 > reason why we should not return the data in its native type?
 > 	I also have questions about RPC2 programming. Is it better for the text of
 > error messages to be transmitted from the client to the server, or should
 > the server just provide a status integer to the client and make the client
 > provide the actual text of the error message based on the error code? Also,
 > is the return value of RPC2 functions normally reserved for RPC2 status
 > information, or can program status information be returned as well? For
 > example, if the RPC2 call is successful, but my function can't find a file,
 > is it a bad idea for me to have the function return some constant not
 > reserved by RPC2?
 > 
 > 	Thanks for the help,
 > 		John