[Os-project-managers] Fork in the Road

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
>>>>
>>>> <minMemory unit="gigabyte">2.0</minMemory>
>>>>
>>>> is a reasonable request in an OSpL file. If the system does _not_ meet
>>>> these requirements, you will want to know about it. How can you get that
>>>> information back? It does not fit into an OSrL file, which is generated
>>>> by the solver. Hence you need to return an OSpL file.
>>>
>>> Get it back in some part of the OSrL file. I am not willing to buy
>>> into getting OSrL back if the call is local and OSpL if the call is
>>> remote. That seems fundamentally flawed to me.
>>
>> The problem with that approach is that the server then has to touch the
>> OSrL file that comes back from the remote server. In other words,
>> encapsulation is violated.
>
> We definitely have some issues to work out.

The way I see it, the problem arises because a remote solve returns  
process information and a local solve doesn't.

The one given is that the solver writes OSrL. This is passed back  
differently depending on whether we have a local solve or a remote  
solve. In the remote case the server can add system information, while  
in the local case this is not
so. There are several ways to deal with this.

1. We allow the server, as we do now, to modify the OSrL file. This  
violates encapsulation.

2. We let the server return a second file (OSpL). This also violates  
encapsulation, and I do not like it because in addition it introduces  
side effects into the solve() method.

3. We enforce encapsulation but let the server write its own OSrL  
file. The only way I see that happening is by allowing the OSrL files  
to have nesting, i.e., a form of recursion. I think this is overkill,  
since we ever only write output in *two* places, the server, and the  
solver. I believe we very explicitly ruled out the possibility of  
daisy-chaining one server onto another, which would allow the server  
to pass a remote solve() on to the remote solver. So it seems we do  
not gain much, but we pay a heavy price. Parsing a recursive result  
file is orders of magnitude harder and more complicated than parsing a  
flat one.

4. We implement two new methods, local_solve() and remote_solve().  
Both are private, and both are called from inside solve() to hide the  
complexity from the user. remote_solve() returns an OSpL string that  
contains an embedded OSrL string. This will look very much like what  
we have now. local_solve(), however, returns an OSrL string. So in  
order to make both conformal to the solve() command that sits outside,  
we have a wrapper around the local_solve() method whose only function  
it is to provide an (empty) OSpL around the OSrL file. This preserves  
encapsulation, avoids side-effects, and provides a unified face to the  
user. The drawback is that solve() returns OSpL instead of OSrL, but I  
consider that minor, and we could get around it by shifting some of  
the names around. (Is there any letter in the alphabet that we could  
sacrifice for this?) To me this is the cleanest solution by far.

Cheers

gus