Hi, Felipe
Between lines, keeping only relevant paragraphs
El 12/09/2011 12:02, Felipe Huici escribió:
"
type="cite">
1.
Creation, installation, and deletion of compositions,
including dynamic reconfiguration and querying of Block
variables as things are running. I think the main issues to
iron out here are:
- Figuring out the interface between the GUI
and Blockmon. Right now BM's interface is a CLI, but going
forward, and in terms of the GUI, this should likely change.
What I think would be best is to provide a simple
Python-based XML-RPC daemon/proxy: the back-end would call
the functions the CLI is calling today, and the front-end
would receive XML-RPC calls from the GUI (hopefully using
XML-RPC this is ok with you, we tend to favor it since it
requires very few lines of Python code to use). The
advantage of this proxy is that it would let us run, if
needed, the GUI on a separate machine than Blockmon (e.g.,
this might be useful if we want to run a 10gb experiment for
the demo, since a laptop (i.e., the GUI) won't have such
hardware).
It is OK for us. I guess there should be a WS API in python for
this, but we can wrap later if needed.
"
type="cite">
Andrea, maybe you can start by giving us a full
list of the commands supported by the CLI? Also, the GUI
will need to generate Blockmon XML, this means that we need
to clearly define and finalize what this will look like.
Andrea, can you send Jose Maria a version of what this XML
looks like today and update him as changes happen? Today's
version is probably what's in D4.2 rather than the
implemented Blockmon version.
In the meanwhile, we will try to install and having a permanent VM
running BM at Optenet. Any problem, we will ask.
Actually this functions/parameters is what I see in the
specification for D5.2., at least regarding communication.
"
type="cite">
- Block parameter types: the GUI could benefit
from block parameters having some sort of type so that it
knows whether to display a drop-down box, text field, etc,
etc. Jose Maria, could you start this effort by telling us
what sort of types you would need to know about? (in other
words, which types of forms/buttons/etc you envision using?)
Ok, tomorrow. In a first comment, we can represent any kind of input
object in a web form, the issue is how to map parameter types into
input objects. I will provide a list.
"
type="cite">
2.
Displaying composition results
Jose Maria suggested, and I completely agree,
that the demo would be incomplete if we didn't have a
separate tab that graphically displays the results output by
the composition. I'm not sure where the breakdown is between
what Optnet can generally provide and what the
application/composition writer needs to code, perhaps
someone has suggestions?
I have been thinking on it. Given that at the end we may not having
user profiles (everybody can do anything on authorized
applications/blocks/whatever), I suggest to have "views". A view for
BM compositions, another for BM compositions of compositions (for
the controller), a view for data at BM, etc.
The view for data could be the dashboard + the reporting menu. The
user switches from the component view to this one in a menu (better
than a tab, as should may be kept for different active
compositions), or clicking on the blocks or tabs.
"
type="cite">
Please
provide feedback :)
Done :-)
Thanks a lot for your support!
regards
Jose Maria
|