[Os-project-managers] Updates to OSoL schema

[Hotmail (majxuh)]

Gus
Here are some thoughts on all your suggestions. As said, in general, it is 
good!
I actually prefer to have the "outputStream" wrapping the "printlevel" and 
"programComponent" inside.
If you take a look at log4j, it's essentially "category" (your 
"programComponent") wrapping "appender" (your "outputStream") and "priority" 
(your "printLevel") inside.
Our "wrapping" sequence should be yours, instead of log4j's. OSoL is to 
facilitate an option instance, i.e. a concrete case for logging instruction, 
whereas log4j is to facilitate a general logging need.

We can leveraging some of the good naming conventions in log4j. I will 
mention some later, but we can certainly talk more tomorrow at 11:00.

---
1. There is a new element added to the <job> element, <outputOptions>.
<outputOptions> consists of an optional <stdout> element, followed by
zero or more <outputStream> elements.
---
Should we simply say <logging> instead of <outputOptions>?  output is too 
general. The whole OSrL is about output.

---
2. <stdout> has an optional attribute "defaultPrintLevel" as well as
an optional boolean attribute "returnFromRemoteSolver", which will
replace the <other> mechanism we implemented recently. I hope this is
not too much work, and I hope that the current approach is more
unified and therefore better. <stdout> also has an optional sequence
of zero or more <special> elements, where special print levels can be
set for different areas/components of the code. Unlike Ipopt we can
add this customization feature at little extra cost, and I think it
will be worth it.
---
If you look at log4j, stdout is NOT singled out. stdout is just another 
"appender" or "outputstream" in your world.
You <special> is similar to the <param> children of <appender> in log4j.
I don't quite like the naming of <special>. I 'd rather have 
<programComponent> (or <category> in log4j) as a child element, and 
printlevel (or priority in log4j) as an attribute.

---
3. The intent of the "returnFromRemoteSolver" is to return the stdout
capture to the local machine. For a local serve I think it should do
nothing (although I can be convinced otherwise, if that turns out to
be easier to implement).
---
I don't think this returnFromRemoteSolver is necessary.
In fact, I think "stdout" is misleading. In log4j, the convention is just 
called "console".
In fact, a console is just treated as "console", no redirect.
If the user wants the console output to be in OSrL, we may reserve a special 
"outputstream" name, e.g. "return", or just "osrl".


---
4. If the <stdout> element is missing, there should be a suitable
global default print level, just so that we have covered all the angles.
---
There should be a suitable global default print level for all outputstream 
anyway. We should be able to set that in the OSoL/OSrL schema.


---
5. The <outputStream> element is similar to the <stdout> element,
except that it has a mandatory attribute "fileName" instead of
"returnFromRemoteSolver". This underscores that we do not return
files. In fact, the desired behavior is to intercept the presence of
this element in the java servlet and to throw an error if encountered,
as suggested by Kipp this afternoon. For a local solve, on the other
hand, the user is king and can do pretty much whatever makes sense at
the time. There can be as many files as necessary, with as much detail
as needed, and customized as to the area/component that writes the
output.
---
I think you should think of outputstream as more general. If you take a look 
at the log4j xml, you see lots of other types of outputstreams or appenders
such as email appender, telnet appender, console appender, beside just the 
file appender. So the mandatory "fileName" is may not be a good idea.
We shall discuss.

---
6. As for the implementation, I envision proceeding along the lines of
Andreas Waechter's code in ipopt. There is an array of output streams,
each with an array of print levels (one print level for each
area/component of the code). This array is populated by the OSoL parser.
---
This sounds right. In a word, the implementation should line up with the 
schema structure.

---
7. Every piece of output is sent to a global output handler that
checks each of the output streams to see if the print level and
area/component allow the item to be printed to that stream.
---
This sounds right. Global handler or not, I am not sure yet. I am not 
particular on the way we implement, as long as the logging code doesn't do 
unnecessary checks.

---
8. I still think that we should have a two-tiered print level
hierarchy, with only the first layer accessible to production code,
and both layers available to a code compiled in Debug mode. The
distinction can be made by defining a global variable _DEBUG (in fact,
I believe this variable is defined already), and hiding each debug
print behind an #ifdef _DEBUG ... #endif construct.
---
By "two-tired", you mean compile time, and run time? I think so, because 
it's going to speedup run time process. The "outputoptions" of course, is 
just for run time, right?

---
9. If we can get agreement on these basic design features, then we
should move on to defining the areas/components as well as the print
levels we want to make available --- here we can again look to Ipopt
for guidance.
---
Defining the areas and components is, remember implementation specific. It 
may not be appropriate to define them or standardize the string values in 
the schema.
Note, no part in the OS framework tells us how to name the classes. In fact, 
the OS framework doesn't even say you should use which language.

---
10. And finally we will have to classify each of the 2000 or so print
statements by area/component (easy) and print level (deadly boring and
tedious).
---
It's up to our design. If our design is well-thought, flexible and 
extensible, it might turn out to be not that tedious.

Jun