[blockmon-demons] RE: [blockmon-dev] Addition to the wiki/list


chronological Thread 
  • From: Felipe Huici < >
  • To: "'Jose Maria Gomez Hidalgo'" < >, " " < >, " " < >
  • Cc: Saverio Niccolini < >
  • Subject: [blockmon-demons] RE: [blockmon-dev] Addition to the wiki/list
  • Date: Mon, 12 Sep 2011 10:02:03 +0000
  • Accept-language: en-US, de-DE

Title: JOSÉ MARÍA GÓMEZ HIDALGO

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
Sent: Monday, September 12, 2011 9:19 AM
To: ;
Subject: [blockmon-dev] Addition to the wiki/list

 

Dear all

I have added myself to the wiki as a developer, for the GUI issues.

We are currently working on implementing the mock-up defined by Felipe (thanks again).

The phases we have discussed with Felipe are:

1. Implementation of a single node BM GUI, no controller, it will only allow to define, combine and run compositions within a single machine. It will be presenting the results of the execution as the appropriate charts as well. We need a view of a composition of compositions. There is only an intended type of user, the programmer/user of the application.

2. After that, the implementation of a distributed BM platform including the controller and an additional view for the physical/topological deployment of the compositions among several machines, as assigned by the controller. This view will be available to a different kind of user, the operator, with access to the actual status of the machines (physical location, CPU, RAM, HD).

3. Finally, we will be addressing the rest of the components of the GUI (WPOC etc.), as the specification is still under definition.

For (1) we will be working with the next version of BM, and we will start with the info from the current version along with those examples you can provide to us, and the available documentation.

Regards

  Jose Maria

--

C/ José Echegaray nº 8
Edificio 3, 1ª Planta, módulo 1
Parque empresarial Alvia
28230 Las Rozas 
Madrid, España 

 

JOSÉ MARÍA GÓMEZ HIDALGO
R&D DIRECTOR AND TRAINING DIRECTOR

T  +34 902 154 604   Ext.1059

 

 

F  +34 91 357 54 33

 

">

www.optenet.com

 

M  +34 660 619 960

 

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.

§