[Os-project-managers] Fork in the Road

[Jun Ma]

All,
I finished reading this whole discussion on the "Fork in the Road" email 
thread.
I am feeling that there are too many converging and diverging ideas going on 
at this moment, and I am getting more and more unsure of what our best 
design approach is.
Several major ideas including leveraging on OSpL, the distinction of "local" 
and "remote" solve, reflect fairly new concepts, which could be different 
from what was originally envisioned.
I am also not sure whether I really understood and digested all the issues 
discussed so far and whether they follow the OS Constitution.

Three things I want to point out here:
1. A locally solved optimization service has always been envisioned just as 
a special case (not a parallel case) of the a distributed optimization 
service, so information being communicated back and forth is of course less 
in the local scenario.
Ideally clients really don't need to know the difference between the local 
solve or remote solve.  Local and remote solve are just two different 
implementation, and the OS Framework doesn't say or doesn't intend to limit 
much of how things are implemented.
In fact, WSDL is just one standard that we propose for SOAP based Web 
Service implementation, in which we specified 6 methods/signatures. For a 
local solver, it can also implement the 6 methods/signatures in whatever the 
programming language specific APIs.
Current trend in the IT industry is more or less  tight integration of 
services, like the various cloud services. "Tight" means to me "feeling" 
like a local service.

2. ospl is designed to communicate dynamic information, i.e. intermediate or 
running information.
How ospl should look like, has so far just been experimental, including 
whether it should be serving both in the request and in the response.

3. Again, I hope we can also think simply of this question -- What is OSrL? 
OSrL is nothing but the result we EXPECT to receive when we send OSiL plus 
an optional OSoL to an OS compatible service, local or remote.
By OS compatible, we simply mean the signature and the arguments follow the 
WSDL and Schema. In the thesis, it is also stated like this in a similar 
way, very explicitly, several times.
There are no extra requirements or concepts, such as layers, in the original 
intent. When I talked about layer in the thesis, I basically want to convey 
the ideal that OS DOES NOT need to worry about the underlying transport 
layers, because it is an APPLICATION level protocol.
A secondary question might then be, if our OSrL schema is good or bad. By 
good, I mean, does OSrL live up to the "EXPECTATION" in most of the common 
practices?


For example, the following simple diagram is just 3 OS's,  You can think of 
the whole diagram as some "creative" combination or use of OS, but OS itself 
doesn't say anything about such combination. OS is just about 1 leg.

client ----os---->tomcat optimization service on a remote 
server ----os----->local os solver service.exe on the same 
server----os---->adapted clp solver that directly takes osil.