[Os-project-managers] Fork in the Road

[Horand Gassmann]

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Guys:
>
> I looks like we made (in my opinion) a serious error in going from  
> 1.0 to 2.0. Open up OSrL schemas for 1.0 and compare with 2.0. The  
> 1.0 is far  more consistent with what Jun expressed as the OS  
> vision. Version 2.0 is not consistent. Notice how we started adding  
> all sorts of "System Information" in addition to the result  
> information. Version 1.0 is far more clean. The children of OSrL 1.0  
> are resultHeader and resultData.

But I remember that 1.0 had its problems too. In particular, it seems  
that it violates encapsulation also in that it sends and receives two  
different pieces, OSpL/OSoL and OSpL/OSrL, respectively. With true  
encapsulation, shouldn't that just be a single item? It's also asking  
quite a bit of the user to remember which option bits to put into the  
OSpL file and what to put into the OSoL file, and on the return it is  
mighty inconvenient to have to look in two places for the information.

In fact, I have always had a bit of a problem with the two-way nature  
of OSpL. I have always felt that there should be two flavors of it, if  
you will, one for sending, and one for receiving. And the OSoL and  
OSrL should be *packaged* within them as separate elements. But maybe  
that could be achieved with a choice element. If the OSpL file  
contains an <osol> element, it is meant to be sent to the server, if  
it contains an <osrl> element it is a return file, and if it contains  
neither, then we can't tell, and we probably don't need to worry about  
it.

Much of that we have already. When we send an OSoL to the server, only  
the  <optimization> element needs to be passed on to the remote  
solver, so we could just convert  the <optimization> element into an  
<osol> element, with proper OSoL (3.0) syntax. (I am ambivalent as to  
whether we need to go back and call the combined file an OSpL file.)  
The server can then strip out the <osol> element and pass it to the  
remote solver. No mess, no fuss. But I think there should be a mandate  
that the server not modify the <osol> element. It is of course free to  
read it, but modifications should be verboten.

This has one particular disadvantage: a local solve() is _different_  
from a remote solve(). A local solve needs to be given an OSoL file  
(or the <osol> element only), while the remote solve() needs the  
larger version. This could be confusing.

On the way back we can do the same thing. The remote server writes an  
OSrL file, which the server reads and packages into an <osrl> element  
in the OSpL(out) file. (No modifying  of the <osrl> element!) The only  
problem I see off the top of my head is that timing information and  
possibly other system-related items can show up in two places. That is  
not nice, but given that there are two different places that can  
contribute this information, I don't really see a way around it.

These are of course major changes to how we do things. I have copied  
to the managers list, so we have a record for later. I also invite  
your comments, of course.

Cheers

gus