[OpenMOLE-devs] Web front-end for openmole.

Romain romain.reuillon at iscpif.fr
Fri Jan 11 20:19:22 CET 2013


A second thought on that one, to clarify:

what I call server here is the OpenMOLE server. Looking at the global 
picture there are 2 servers: the OpenMOLE server and the bioemergences 
server. The bioemergences server will be a client of the OpenMOLE 
server. I think the XML mole files should be stored on the bioemergences 
server. A mole file will be pushed to the OpenMOLE server at each 
execution request.

On 11/01/2013 17:58, Romain wrote:
> It will make the action of updating a workflow more complex and open
> another potential leak of ressources: if a client uploads many workflows.
>
> For the sake of simplicity (of the client an server side) and robustness
> I think that the workflow should be stored by the client. It will upload
> it along with an execution request. In this scheme a workflow update
> means changing a single file on the client side and cannot generate a
> resource leak on the server side.
>
> On 11/01/2013 17:53, Mark Hammons wrote:
>> I was thinking of this less as an optimization, and more of a
>> convenience. Mathieu has told me that Bioemergence uses a common set of
>> WFs constantly. Rather than forcing the scientist to continually
>> reupload them each time he has an experiment to run, he can choose WF 1
>> from the server and just enter the necessary data.
>>
>>
>> On Fri, Jan 11, 2013 at 5:49 PM, Romain <romain.reuillon at iscpif.fr
>> <mailto:romain.reuillon at iscpif.fr>> wrote:
>>
>>     I think it is premature optimisation. I will be more state to store
>>     and manage on the server side, making it less robust. As the
>>     workflow XML are not that big and an execution is very long compared
>>     to the time to upload a workflow. From my point of view, this
>>     optimisation doesn't worth the complexity it implies.
>>
>>
>>     On 11/01/2013 17:43, Mark Hammons wrote:
>>
>>         I was thinking that the mole submission form could have a way to
>>         save
>>         commonly used workflow batches as a kind of template, so the
>>         scientist
>>         can just input the new data he wants processed by the workflow
>> each
>>         time. In the Bioemergence case the well known WFs could be added
>>         once
>>         and then used many times by Biomergence scientists.
>>
>>
>>         On Fri, Jan 11, 2013 at 5:40 PM, Mathieu Leclaire
>>         <mathieu.leclaire at iscpif.fr <mailto:mathieu.leclaire at iscpif.fr>
>>         <mailto:mathieu.leclaire at __iscpif.fr
>>         <mailto:mathieu.leclaire at iscpif.fr>>> wrote:
>>
>>              It sounds good. It looks like the schema we drew with Manu
>>         the other
>>              day: a server application generates OpenMOLE executions
>>         according to
>>              a xml serialized workflow and a set of parameters. In the
>>         case of
>>              Bioemergence, the serialized WF are well known and should be
>>              available for the scientist through a list (it does not
>>         need te load
>>              a WF or it can do that optionaly). Each execution is mapped
>>         to an
>>              ID, which permits to ask the server for the execution
>> states.
>>
>>              Congrats Mark, it's 5.30pm and you're still awake :) !
>>              Le 11/01/2013 17:27, Mark Hammons a écrit :
>>
>>                  I was discussing this with Matthieu the other day, but
>>             I have a
>>                  little demo application for play built, and it looks
>>             very simple
>>                  and easy to use/understand, so we're thinking the play
>>             framework
>>                  would be appropriate for an openmole GUI.
>>
>>                  I have a couple things I need clarified though. We can
>>             have the
>>                  web interface be a part of the openmole process, so
>>             that when you
>>                  start openmole, the play server is started and you can
>>             view the
>>                  progress of your work, but I think that is not a good
>>             idea unless
>>                  the openmole process becomes a server in of itself.
>>
>>                  I am thinking the webserver should create and monitor
>>             open mole
>>                  processes. I was thinking there would be a web form
>>             where the
>>                  scientist can fill in the data and information
>>             necessary, select
>>                  a serialized mole xml from his computer, and tell the
>>             server to
>>                  run the mole. Then the server would initiate the
>>             openmole program
>>                  with the parameters, give the scientist a process ID,
>>             and then the
>>                  scientist could view and control the progress of the
>>             mole from
>>                  another webpage. Does this sound good to you guys?
>>
>>                  --
>>                  Mark Edgar Hammons II - OU Student | Contributor to
>>             OpenMOLE
>>                  <http://www.openmole.org/>
>>
>>                  Cell - 1 (405) 928 8206
>>             <tel:1%20%28405%29%20928%208206>
>>             <tel:1%20%28405%29%20928%__208206>
>>                  Email - markehammons at gmail.com
>>             <mailto:markehammons at gmail.com>
>>             <mailto:markehammons at gmail.com
>>             <mailto:markehammons at gmail.com>__>
>>
>>
>>                  _________________________________________________
>>                  OpenMOLE-devs mailing list
>>             OpenMOLE-devs at iscpif.fr <mailto:OpenMOLE-devs at iscpif.fr>
>>               <mailto:OpenMOLE-devs at iscpif.__fr
>>             <mailto:OpenMOLE-devs at iscpif.fr>>
>>             http://fedex.iscpif.fr/__mailman/listinfo/openmole-devs
>>             <http://fedex.iscpif.fr/mailman/listinfo/openmole-devs>
>>
>>
>>
>>              _________________________________________________
>>              OpenMOLE-devs mailing list
>>         OpenMOLE-devs at iscpif.fr <mailto:OpenMOLE-devs at iscpif.fr>
>>         <mailto:OpenMOLE-devs at iscpif.__fr
>> <mailto:OpenMOLE-devs at iscpif.fr>>
>>
>>         http://fedex.iscpif.fr/__mailman/listinfo/openmole-devs
>>         <http://fedex.iscpif.fr/mailman/listinfo/openmole-devs>
>>
>>
>>
>>
>>         --
>>         Mark Edgar Hammons II - OU Student | Contributor to OpenMOLE
>>         <http://www.openmole.org/>
>>
>>
>>         Cell - 1 (405) 928 8206 <tel:1%20%28405%29%20928%208206>
>>         Email - markehammons at gmail.com <mailto:markehammons at gmail.com>
>>         <mailto:markehammons at gmail.com <mailto:markehammons at gmail.com>__>
>>
>>
>>
>>         _________________________________________________
>>         OpenMOLE-devs mailing list
>>         OpenMOLE-devs at iscpif.fr <mailto:OpenMOLE-devs at iscpif.fr>
>>         http://fedex.iscpif.fr/__mailman/listinfo/openmole-devs
>>         <http://fedex.iscpif.fr/mailman/listinfo/openmole-devs>
>>
>>
>>
>>
>>     _______________________________________________
>>     OpenMOLE-devs mailing list
>>     OpenMOLE-devs at iscpif.fr <mailto:OpenMOLE-devs at iscpif.fr>
>>     http://fedex.iscpif.fr/mailman/listinfo/openmole-devs
>>
>>
>>
>>
>> --
>> Mark Edgar Hammons II - OU Student | Contributor to OpenMOLE
>> <http://www.openmole.org/>
>>
>> Cell - 1 (405) 928 8206
>> Email - markehammons at gmail.com <mailto:markehammons at gmail.com>
>>
>>
>> _______________________________________________
>> OpenMOLE-devs mailing list
>> OpenMOLE-devs at iscpif.fr
>> http://fedex.iscpif.fr/mailman/listinfo/openmole-devs
>>
>
>
>
>
> _______________________________________________
> OpenMOLE-devs mailing list
> OpenMOLE-devs at iscpif.fr
> http://fedex.iscpif.fr/mailman/listinfo/openmole-devs
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://fedex.iscpif.fr/pipermail/openmole-devs/attachments/20130111/35dbf3f7/attachment.bin>


More information about the OpenMOLE-devs mailing list