[Os-project-managers] Fork in the Road
Horand Gassmann
Horand.Gassmann at DAL.CA
Fri Dec 2 07:09:15 EST 2011
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
More information about the Os-project-managers
mailing list