<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Ilias and all,<br>
<br>
thank you. You are right, this point is not clear. I myself don't
have good enough clarity about it because it is even a bit larger
than described below. The main question is - what out of the
scheduling is shared when running the simulation? <br>
<br>
Further, I have some simplifications I would like to suggest, but
that will be relevant only after we answer the question above. With
that I would suggest not to go on with the classes DEECoRun and
related interfaces and the interfaces around scheduler notifier. I
believe a half of it can be dropped.<br>
<br>
Let's discuss it tomorrow.<br>
<br>
Thank you very much,<br>
Tomas<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 14. 2. 2015 19:20, Ilias
Gerostathopoulos wrote:<br>
</div>
<blockquote cite="mid:54DF91D1.9090405@gmail.com" type="cite">Hi
all,
<br>
<br>
with Filip, we made a first iteration on the scheduler and the
support for "DEECo realm".
<br>
After several discussions also with Michal and Vlada on Friday, we
decided to change the way a deeco run (or "simulation") is
assembled and started.
<br>
The results are pushed to the "plugin-architecture" branch (still
several javadoc and tests missing...), also see the attached class
diagrams.
<br>
<br>
The main idea is that a scheduler cannot be started anymore.
Instead, the "scheduler notifier" is started, ie it becomes the
"active" entity. This can be implemented either as a discrete
event notifier, a wall-time notifier, or an OMNET-based one.
<br>
<br>
About "DEECo realm", this becomes a class that is
<br>
(i) a factory for "DEECoNode"s (previously called just "DEECo", it
is basically the main deployable entity with its own runtime,
runtime model, components and ensembles)
<br>
(ii) the main entry to start the application. Upon startup, it
passes the control to the scheduler notifier. The scheduler
notifier has to be created outside of the realm and injected
through the realm's constructor.
<br>
We prepared 2 implementations of the realm, one for running deeco
in "real" deployment ("DEECoRun"), one for simulation runs
("DEECoSimulation").
<br>
<br>
We would like to ask your opinion on these changes before we go on
to finalize the classes and update the tests.
<br>
Maybe we could have a short meeting on Monday about this. I won't
be available from 10:00 to 14:00 (2nd phase of the IRM
experiment), but any other time is OK for me.
<br>
<br>
Thanks,
<br>
Ilias
<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
DEECo mailing list
<a class="moz-txt-link-abbreviated" href="mailto:DEECo@d3s.mff.cuni.cz">DEECo@d3s.mff.cuni.cz</a>
<a class="moz-txt-link-freetext" href="https://d3s.mff.cuni.cz/mailman/listinfo/deeco">https://d3s.mff.cuni.cz/mailman/listinfo/deeco</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Tomas Bures, Ph.D.
Associate Professor
Department of Distributed and Dependable Systems
Charles University
Malostranske nam.25
11800 Prague 1, Czech Republic
<a class="moz-txt-link-freetext" href="http://d3s.mff.cuni.cz">http://d3s.mff.cuni.cz</a>
Phone: (+420) 2 2191 4236
Fax: (+420) 2 2191 4323</pre>
</body>
</html>