Back to Operating Systems Home Page

A4 - Re: Conflicts in spec

On Wed, 8 Apr 1998, Nadim Abdo wrote:

> In the END command description you say:
> 
> 'the server then prepares itself for receiving further commands possibly
> including file-transfer, compilation or run commands'.
> 
> On the next page's state description you say
> from RUN to READY following the end command. 
> 
> You can't do file transfer or compilation in the READY state.

Correct. However, the state specifications need not be interpreted
as strictly as the rest of the protocol, since it's not a spec
on the *communication* between client and server, but rather
on the *implementation* of the server. While changing the
protocol commands and answers would make a daemon incompatible
with a client, changing the implementation of the server (maintaining
the syntax and meaning of the commands) does not necessarily break
compatibility.

So you are allowed some play in the way you implement your server as
a state machine. In particular, it does make sense that after an
END command you are allowed to issue either a new RUN, or a new
SRC, MAKE sequence. Think for exmaple of the case in which you
END the program because you notice a bug. You may want to submit
some sources to correct the bug (possibly just one file of 124
separate source files composing the whole application), recompile
and rerun.

> On the same topic, you say about the END command 'If it's sent after the
> application has terminated it's simply ignored but the server send the
> reply message anyway' (I assume you mean 011 Current app run terminated).
> 
> END can only be used in the RUNNING state, therefore the app cannot be
> not running if an END is accepted. If END is sent at any other time, I
> assume a 101 Bad Command should be returned as with all the other attempts
> to run in an illegal state. 

Correct. Please fix the specifications in this sense.

Ciao
Franco