[Os-project-managers] Fwd: Re: Meeting on Wednesday

[Kipp Martin]

-------- Original Message --------
Subject: Re: Meeting on Wednesday
Date: Mon, 5 Dec 2011 17:27:10 -0600
From: Jun Ma <majxuh at hotmail.com>
Reply-To: Jun Ma <majxuh at hotmail.com>
To: Horand Gassmann <Horand.Gassmann at Dal.Ca>, Kipp Martin 
<kipp.martin at chicagogsb.edu>

I will get the  layers.pdf.

I feel a bit puzzled by the following sentence. But we can discuss on
Wednesday.
> We should introduce  some stronger language there to delineate a bit
> better who reads what

Talking about layers, first a word on OSI (Open Systems Interconnection
model, not the COIN Open Solver Interface). OS is not the equivalent of 
OSI.
model.
(The Open Systems Interconnection model is a product of the Open Systems
Interconnection effort at the International Organization for
Standardization.
It is a prescription of characterizing and standardizing the functions of a
communications system in terms of abstraction layers.)

Rather OS, in a sense,  is one of the layers specified in OSI -- the
application layer.
We can of course discuss whether within the OS Protocol, we specify further
layers. But again, I never even thought of that; nor did I restrict that.

Whereas,  It is natural that the OSI model is layer based  (linearly pack
from top to bottom), it may not quite apply in OS.
The OSI model is about VERTICAL technical transport, while OS is about
HORIZONTAL domain logic.
For one, the application level logic of optimization process is NOT linear.
In fact the flow can be anything, e.g. the master optimization launches two
suboptimization in parallel.

So, it might just be two totally different things between the layers
mentioned in the OSI model and the OS optimization flow process.
The goal of OSI is to delineate and restrict and it is possible in that
area.
But, is the goal of OS also to restrict and delineate the implementation
(e.g. how to design the sever-side tiers)? Is it even possible or is it the
right thing for OS to interfere with?

Today, a tiered server side OS implementation is just our choice of
implementation. which may have given us the never intended impression that
OS was designed to be layered.

Again I am not trying to object to anything. In fact, I am more and more
leaning toward either the simplest design or a very thoughtful "layered"
design.
In fact, there is a mentioning of OSfL (OS flow Language) in the original
thesis. But that was intended to orchestrate different optimization 
services
at a higher level than other component OSxLs.

I just hope that we don't confuse between different concepts and just mix
them together. This should pave the way for our Wednesday discussion.

Jun



> as you may recall we agreed to meet this week on Wednesday at noon
> Central. Hope this still works for everybody. Kipp an, I had a long
> discussion about OSoL today, and I think we finally agreed that  probably
> OSoL is not such a bad document after all, even in its  current version.
> However, we also agreed that it would be useful to  get consensus on which
> layer of the software reads which elements (and  which layer writes to
> these elements).
>
> To that end, we wanted to resurrect our original diagram layers.pdf  (in
> the figures folder) and see if we can vet it carefully. Jun, can  you make
> sure to print out this diagram for the meeting on Wednesday;  I think it
> is essential that we each have a copy in front of us.
>
> We also talked about the top level elements in the OSoL schema in this
> context (first set of bullets in section 3.2). We should introduce  some
> stronger language there to delineate a bit better who reads what  (and in
> section 4.2 we should have a similar set of bullets that  spells out more
> clearly who writes what).
>
> Talk to you Wednesday.
>
> Cheers
>
> gus
>
> -------------------------------------------------------
>
> Horand I. Gassmann, Professor
>
> School of Business Administration, Dalhousie University
> 6100 University Avenue, PO Box 15000
> Halifax, Nova Scotia, Canada, B3H 4R2
> ph. (902) 494-1844
> fax (902) 494-1107
>
> http://myweb.dal.ca/gassmann/
>
>