[Os-project-managers] Fork in the Road

[Horand Gassmann]

Horand Gassmann <Horand.Gassmann at dal.ca> wrote:

> Kipp Martin <kmartin at chicagobooth.edu> wrote:
>
>> Hi Gus:
>>
>>>
>>> Let me add another thought. This whole discussion has been extremely
>>> stimulating, and it has made me realize that there is a fundamental
>>> difference between input and output methods as far as encapsulation is
>>> concerned. We do not have the same problem with the OSoL format, because
>>> we can always pass the entire OSoL file down the line. The server reads
>>> its pieces, but it does not have to "decapsulate" the parts that need to
>>> go to the server. You pay the price of a bit of redundancy, because what
>>> the server passes to the solver has information we know to be useless,
>>> but that is trivial. It's the return path that is hard.
>>
>> Aha! You say:  "You pay the price of a bit of redundancy, because what
>> the server passes to the solver has information we know to be useless,
>> but that is trivial."
>>
>> Then solver writers need to know what is useless, i.e. what they  
>> should and should not try to read. If I am a solver developer I  
>> would assume that I should be processing ALL of the OSoL file. I am  
>> pretty irritated if I get useless information. This is what I keep  
>> coming back to: OSoL should only contain information relevant to  
>> the solver and OSrL should only be information coming back from the  
>> solver. We had things correct with version 1.0 and then really  
>> screwed up in going to 2.0. Indeed, I would favor a modification to  
>> your previous option 4 in that when we do a remote_solve()  we  
>> package the OSoL inside OSpL, then strip out the OSoL and send it  
>> to the solver.
>
> I would accept that as a friendly amendment.
>
>> Having OSpL information inside OSrL and OSoL is fundamentally wrong  
>> in my opinion.
>
>> My Mantra: "OSoL should only contain information relevant to the  
>> solver and OSrL should only be information coming back from the  
>> solver."

I had a look this morning at OSpL, and it seems that if we go the  
route of a modified option 4, with OSpL containing OSoL being sent to  
the server, then we are going to have a hard time shoehorning the  
return file (containing process information and an OSrL file) into the  
same OSpL framework. According to Jun`s thesis, OSwL (for "write  
process information") is available. (So is OSzL --- for "this is the  
last change of this kind we will ever make"...)

So I would modify Option 4 yet again slightly:

solve()  receives on OSpL file. The server (or perhaps a local layer  
prior to sending the stuff to the solver) can act on the  
process-related bits and strips out the OSoL file contained in it,  
which it passes to the solver. The solver returns OSrL, which the  
server (or the front end to the local solve) packages inside a schema  
file (with a yet-to-be-determined name) and then returns to the user.  
This is symmetric, encapsulating, and clean.

Cheers

gus