\division{OSSolverService rules}\label{section:OSSolverServiceRules}


1. We do not write to, or read from, the OSoL file.

2. We do a local solve if and only if the serviceLocation string is empty. If the serviceLocation string is not empty we do a remote solve.

3. If we are doing a local solve the OSoL file is passed on to either the default solver or the solver we specify.  If we are doing a remote solve (or kill, send, retrieve, knock, getJobID)  the OSoL file is passed on to the solver service specified in the service location string. 


Implementation:

I think that you are making it more complicated than it is. Here is the way I look at situation (and the way OSSolverService works).  For the moment pretend there is no such thing as a config file.


Step 1: determine if we do a local or remote solve.  I think it is critical that this be step 1.

Step 2a: If the the answer in Step 1 is to do a remote solve, then pass the OSoL file and the osil file given at the command line to the remote solver process. If the OSoL file also specifies an osil file it is up to the remote solver to pick which one to choose. If no osil file is given at the command line, but an mps or nl file is, translate to osil and pass along to remote solver.

Step 2b: Assume the answer is no, we do a local solve. Pass the osil file at the command line to the solver (either the default solver or one specified at command line) along with the OSoL file. DO NOT read or look at the OSoL -- just pass to the solver. If there is no osil file specified at the command line look or nl or mps and translate to OSiL. If there is no osil, nl, or mps throw an error.


Now we add the complication of a config file.

Step 0: Parse the command line and config file. (By the way, in OS/src/OSParsers this is what  OSParseosss.l does). The command line overrides any values in the config file if there is a conflict. Pick up any additional options specified in the config file such as the solver. Now go to Step 0.
