R. Clayton (rclayton@monmouth.edu)
(no date)
According to the requirements, a "service-call spec consists of a call-name
spec followed by zero or more call parameters." If a service-call is
specified with zero parameters and calls are bound to prototypes with no
return type (void), then there is no way to indicate an error has occured to
the client-side srpc run-time user.
I can read your message two different ways, and come up with a different answer
for each way. I'll start with the way I don't think you mean. If the
developer of the sRPC service feels it makes sense to have a call that takes no
parameters and returns no values, then so be it. (That's actually a good test
question: for what purpose would such a call be used?).
The second reading, which is the one I think you mean, is based on a
mis-interpretation: the contents of parameters and return values is entirely
under the control of the client and server code provided by the sRPC service
developer. The only thing the sRPC run-time should do with those contents is
faithfully move them between client and server.
This means there is no way to for the sRPC run-time to indicate back to the
caller any errors that occur during the call. (This does not mean that the
run-time should not handle errors; it just shouldn't try reporting them back to
the caller.)
Is it acceptable to change the binding such that the prototypes return an
integer or boolean value to indicate errors? This is the method used in the
Comer-Stevens example.
No. The run-time system may do whatever it wants between the client-server
interfaces (as long as it implements the calls correctly), but the interfaces
out belong to the developers and the run-time system should not impose. This
is, admittedly, a draconian point-of-view. For example, java rmi requires that
interfaces methods handle the RemoteException exception, but people have
criticized rmi for just that reason.
This archive was generated by hypermail 2.0b3 on Tue Apr 06 2004 - 13:30:06 EDT