[Os-project-managers] Fork in the Road

[Kipp Martin]

Hi Gus:

>
> But here`s the deal. I have looked at the OSSolverService code as well
> as the solver interfaces, and it is not clear to me any more how the
> input gets passed. Every solve method I have looked at seems to be just
> solve(), no arguments, nothing. My intent, crystalized over several
> iterations is this:

You are looking at different solve methods -- the solve method for 
OSSolverService and the solve methods for the actual solver interfaces. 
The solver interfaces should remain EXACTLY as is. The local solver 
interfaces solve() method will NOT take OSpL. The local solvers take 
OSoL and write OSrL. Just like always.


>
> We pass to solve() an OSpL file/string that contains an OSoL file.
> Inside solve() there are two methods, local_solve and remote_solve() (or
> lsolve and rsolve if you prefer).

I don't think so. Inside the OSSolverService solve(), if it is a local 
solve then it just sends the OSiL and OSoL to local OSSolver interface. 
If it is a remote solve, it puts it inside OSpL and sends it off. The 
solve() method in OSSolverService should do the packing and unpacking.
>
> rsolve() passes the OSpL string to the remote server. The remote server
> processes the pure OSpL portion (or ignores it, I suppose). It strips
> out the OSoL component and passes it to the remote solver. The remote
> solver returns an OSoL string to the server, which packages it into an
> OSwL (!) file --- the OSpL and OSwL files look sufficiently different to
> warrant two separate schemas. The OSwL file is then returned to the caller.
>
> The local solve does similar things, except it strips out the OSoL
> portion itself and passes it to the local solver. The local solver
> returns an OSrL string, which the local solve packages into an OSwL
> file. (Note again: not OSpL --- the differences between what is sent and
> what comes back are just too great to shoehorn everything into the same
> schema.)

The local solve (just to be clear, I am talking about the solve() in 
OSSolverService) doesn't have to do any stripping. It just sends OSoL 
and OSiL to the local solver. However, if a remote solve is called for 
then it puts it inside OSpL and sends it off.
>
> Either way, the user provides OSpL and receives back OSwL.

I definitely do not agree. The user should never have to worry or know 
about OSpL and OSwL. We are going to make life far too hard for guys 
like Mike and Bill.
>
> In essence, the local solve is going to have to assume some of the
> responsibilities of the remote server, namely to strip out the OSoL file
> and wrap the OSrL into an OSwL, perhaps together with some output it
> generates from the pure OSpL portions it was handed.
>
> Does this make sense?

No, I think you are making it a LOT more complicated than necessary. But 
I may well have misread this. I thought we were converging, but now 
after reading this email we diverged.

Cheers


>
> I know it is very different from what we had before, but it is
> internally consistent. As I said, names can be changed to protect the
> innocent --- I am not overly hung up on that.
>
> But it is going to be a bear to write the OSpL files. We will have to
> make a large API available to support this process.
>
> Cheers
>
> gus
>
>
>
>


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
--