Hi Jose Maria, So following the plan :), let's concentrate on step 1 for now and try to get this up and running as quickly as we can. As you mentioned, this GUI has a single
type of user (the application writer), so likely there's no need to provide a log-in (the assumption here is that the person using the GUI is the person owning the computer and the person owning Blockmon; I think this should be good enough for the single node
BM GUI). As you mention, this GUI has essentially two main functionalities: 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). 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. - 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?) - At some point it would be good for us to be able to run an early prototype of the GUI to be able to provide more direct feedback 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? Please provide feedback :) -- Felipe From:
[mailto:
On Behalf Of Jose Maria Gomez Hidalgo Dear all --
This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby informed that you shall
notify the sender immediately and delete the message. Dissemination, distribution or copying of this message is strictly prohibited. OPTENET, S.A. is entitled to complete the corresponding legal actions against people that access unlawfully to the content
of the messages that have been sent from any of the companies within the structure of OPTENET, S.A. This communication is for information purposes only and should not be regarded as an official statement from OPTENET, S.A. Email transmission cannot be guaranteed
to be secure. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. This email has been scanned by our Antivirus system. |
Archive powered by MhonArc 2.6.16.