Rename Master and Slave to more proper names
The master and slave have names which are racists at not do not fit anymore for what they´re actually doing.
Activity
Proposal:
GUI:
- openpassGUI.exe
Master:
- SimManager, Main, openpassManager.exe
Slave:
- Sim, Simulation, Simulator, SimAgent, SimRunner (Run) openpassRun.exe
Edited by Michael Scharfenbergchanged milestone to %Release v0.8
I would suggest to write openPASS with correct capitalization. Therefore I suggest:
GUI: openPASS_GUI.exe
For the slave I would strongly recommend the term core. This is a common term used within the area of simulation. Even in the source code we use core quite a lot already.
Slave: openPASS_Core.exe
Master: openPASS_Manager.exe
Your proposal would be ok for me. I just have minor issues with the openPASS_Manager. I think the term Manager is a bit too general here. (What does it manage?)
Thus, I'd go with something like openPASS_ProcessManager. On the other hand, now the term gets a bit long to read, which lets me think about dropping the
openPASS_prefix as a whole.So I'd end up with:
gui.exe
core.exe
processmanager.exe
Hello Everyone. I just want to point out that the user has to run these applications from the command line and thus their names should not be to generic or to complicated to to type. I would fully support naming the components gui, core and processmanager but I would name the actual executable of the GUI OpenPASS or OpenPASS.exe on windows This is what everyone would expect when he or she installs openpass and tries to run it.
-
I still have a little doubt about the word core for the slave. From my point of view is the slave a kind of framework. It consists of core which is responsible to organise and orchestrate the simulation. The main functionality comes then later with the modules and components.
So my point is that the word core is great to describe something from an architectural point view, so like there could also be a core.dll or something. But from an executable I would aspect a word which is desciptive in a way so I can guess what will happen, when I start it.Is this comprehensible?
What it really does is , it runs a simulation... so maybe opSim.exe
Edited by Michael Scharfenberg
@all Please comment
-
- For the rest I'd like to keep a prefixing...
-
- openPassSlave(.exe) -> opSimCore(.exe)
- openPassSlave.xml -> opSimCore.xml
-
- openPassMaster(.exe) -> opBatchProc(.exe)
- openPassMaster.xml -> opBatchProc.xml
-
-
I like the op prefix.
For the master I would think of two cases:
- Master will get more responsibilty in the future to manage or orchestrate the simulations --> I would go with Manager
- Master will be merged into the GUI as it only triggers the start of simulation --> Master name wouldn´t matter, could be Manager, could be Master for the rest of its lifetime
-
The current master implementation does more than just executing a batch of simulations. At least it holds a reference to each process executed, waits for termination and would also allow to kill a process. That's enough for me to call it a process manager.
The class holding the references is even named
ProcessManagerI just found out ;-)If the master gets more features in the future, a renaming later on would be my preference. But we shouldn't take that into account now, as the plans might change.
I'd endorse prefixing the executables, if it would be a common use case to install openPASS as a system wide application (available in PATH). At least for me, this is not the case.
Edited by Reinhard Biegel
-
Maybe we should shortly brainstorm what is the purpose / the functionality of each executable.
-
GUI
- Main Entrance Point
- Provides Graphical User Interface
- Provides different Plugins for different purposes like creating a system out of components, configuring a simulation, ...
- Creating configuration files
- Triggering the simulation start / stop
- Showing Results, Evaluating Results
-
Master
- Triggering one simulation process for each configured simulation scenario / experiment
- Future / Past : Managing each simulation scenario on different machines, network, cloud,...
-
Slave
- execute one scenario / experiment
- run several simualtions for one stochastically changed scenario / experiment
- Read all configuration files and provide the data to the corresponding modules / components
- Load all needed / configured libraries (agent components, core modules)
- Instantiate all configured agents and ensure the correct data exchange between the components and modules
- schedule / trigger each component and module in the correct order
Please feel free to add here, to get a common understanding.
-
I'm not a big fan on prefices. The main EXE shall be named "openPASS" (GUI?). The rest can be anything as long as the user/developer does not come up with the crazy idea to have the openPASS "lib/bin" folder in his system path ;-)
On the master: It also runs several Slaves simultaneously, while the limit of processes is extracted from the number of CPU cores...
-
- I'm fine with GUI → openPASS, as it will be the main entry point also in the future
- I also go with @rbiegel with the responsibilites of the current master → name it process manager
-
@dfix: I still prefer the
opprefix, as it also nicely groups the processes together in the task-mananger...
So, my choice would be:
- openPASS
- opSimCore (do we need core?) → opSim
- opProcMan
mentioned in merge request !20 (merged)
-
As we started working on fixing this issue, we already came across some stuff
It this really, what you would like to have?
-
opsimulation[.exe] -
opsimulationconfig.xml -
opsimulationmanager[.exe] -
opsimulationmanagerconfig.xml
To be honest, I have a little bit of resentment with the "alllowercase":
- I think it's unreadable, especially for the manager
- It is inconsistent with respect to the other configs we've got, such as 'systemConfigBlueprint'
- And I don't like to introduce a mixture form, such as
opsimulationConfig.xml
So my proposal:
opSimulation[.exe]opSimulationConfig.xmlopSimulationManager[.exe]opSimulationManagerConfig.xml
-
assigned to @tduongquang
assigned to @adascri, @dfix, and @jdobberstein
assigned to @mscharfenberg and unassigned @dfix
assigned to @dschmidtpnj
-
One additional remark: Inside of
30_install_openpass.rstwe refer to the "master" branch of openpass. Starting with 0.8, I'd like to rename this tomainbranch.Any objections?
Edited by René Paris -
https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow
I just wanted to throw stable/unstable/(experimental) into the ring, but gitflow is king ;-)
added Work In Progress label
mentioned in commit 218372db
mentioned in merge request !59 (merged)
removed Work In Progress label
mentioned in issue #94 (closed)
