[Os-project-managers] Some proposals about OSSolverService and OSAmplClient

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
>>
>> 6. I do not like the global variable osoptions in
>> OSSolverService.cpp:183. However, eliminating this might mean that I
>> would have to change the signature of the service methods from, e.g.,
>> solve() to solve(osOptionsStruc *osoptions).
>
> Isn't this being proposed in
>
> http://list.coin-or.org/pipermail/os-project-managers/2011-September/000202.html
>
> Also, there are different levels of solve. When I think of solve as  
> a service method,  I think of the solve in OShL. To me it does not  
> seem like you are suggesting changing the solve method, but rather  
> the method that uses the OShL solve. You are not really suggesting  
> changing OShL signatures, or are you?
>
> Maybe I am missing something, but it seems like a lot of what you  
> are either suggesting or want to accomplish is in
>
> http://list.coin-or.org/pipermail/os-project-managers/2011-September/000202.html
>
> I am pretty confused by your use of solve as a service method.

I am sorry if I was not clear. I am only talking about the six methods  
solve() etc. that are currently found in OSSolverService.cpp. I would  
like to move those out into a separate file or class, so that they can  
be re-used by other executables, such as OSAmplClient.

>> With the exception of point 6. above (and the second half of 1.) this
>> does not change the API, and I am not 100% sure whether 6. and 1.b would
>
> Which API? There are a lot of API's.
>
>
> It seems like we can accomplish a lot of what you suggest by following
>
> http://list.coin-or.org/pipermail/os-project-managers/2011-September/000202.html
>
> without going to OS 3.0.

I have to change the signature of the solve() etc. methods in the new  
class OSSolver. They cannot simply be copied. If this is OK in version  
2.5, then we are in business.

Cheers

gus