No subject

"tomcat optimization service on a remote server" is a BIG Optimization 
Service, and he can send options on all of them. "solverToInvoke", good or 
bad, is just one option that we say, "ok, since it is quite common in 
practice, we will standardize it and build it inside of osol."

Of course, the client doesn't care whether we also use tomcat or not or, or 
whether we also adopt os behind "tomcat optimization service on a remote 
server" in our implementation. All he cares is as long as the first leg is 
OS,  and he can still send the same osil/osol. So the above implementation 
could well be like the following:

client ----os---->optimization service on a remote server implemented in 
c/c++ ----native clp api---->clp solver

or this

client ----os---->IMPACT optimization service (a Java solver service hosted 
on Tomcat that directly exposes the 6 standard methods and solves the 
problems itself using its own algorithms, ALL in one process with one common 
memory space).

All these being said, I am not against changing anything. I just want to 
make sure we change  according to what we intend to change. So we need to 
clear first, on what we intend. If not, or if there are fundamental flaws in 
our original intent or vision, we can revise the intent/vision first and put 
that in OS Constitution.

Kipp I will try give you a call today because I feel it's better that way to 
get us more or less on the same page, so that I  am better prepared for 
Wednesday meeting.
Let me know when is the appropriate time to reach you.

Jun

--------------------------------------------------
From: "Kipp Martin" <kmartin at chicagobooth.edu>
Sent: Sunday, December 04, 2011 4:15 PM
To: "Horand Gassmann" <Horand.Gassmann at dal.ca>; 
<OS-project-managers at list.coin-or.org>
Subject: Re: [Os-project-managers] Fork in the Road

> 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.
> -- 
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>