Chronological Thread 

< Chronological >      < Thread >

---

Ok - you have some reasonable arguments for why this approach has been
used. But if we accept that this is the correct way to be doing this,
then I think the way pcenv is being distributed needs to be changed.

The fact that the cellml_corba_server is started and used essentially in
secret results in me, the user, having no idea that this is being done
and if I was to ever be running multiple instances of pcenv I would in
no way expect changes in one to affect the other unless I specifically
save a file in one and then load it into the other. Same for any of the
other potential tools you mention.

As it stands, I think the cellml_corba_server needs to
distributed/packaged independently of pcenv and the user needs to
explicitly start a local server which pcenv can then use. This not only
explicitly informs the user that they are now running a server process
on their machine but also that this central server will be used by
pcenv. If we're serious about this approach you could even include the
necessary start up scripts to be installed so the cellml_corba_server
can be installed as any other standard server process.

Then when pcenv starts up, it can look for a cellml_corba_server running
on the local host. If it finds one, it can query it to make sure it is a
compatible version for the particular version of pcenv and then connect
to it (or whatever it does). Then the user can be prompted that this
connection has been made. If pcenv does not find a compatible
cellml_corba_server the user can be prompted to create the server (with
download links if necessary, and even suggested commands that could be
executed to startup a suitable cellml_corba_server). Alternatively,
pcenv could still come with its own bundled cellml_corba_server and the
user could be given the option of using that server. In which case pcenv
starts up an internal cellml_corba_server which can not be used by any
other applications/instances and is terminated when the pcenv instance
is exited.


David.

Andrew Miller wrote:
> David Nickerson wrote:
>> I'd just like to check my understanding of this. When I start pcenv the
>> first time, a cellml_corba_server process is started up (if its not
>> already running, I assume) and forked into the background. When I exit
>> pcenv the cellml_corba_server process continues to run, unknown to the
>> user. And then the cellml_corba_server will continue to run, hidden in
>> the background doing who knows what
> It should be idle unless there are clients using it.
>> until I either kill it or reboot my
>> machine?
>>
>> If that is the case, this really concerns me and is something that pcenv
>> should definitely not be doing.
>>
> By doing this, it allows several features to work:
> 1) You can have two PCEnv windows open at the same time on your
> computer, and they will correctly interact with each other (e.g. changes
> to the loaded model list made in one window will take effect in the
> other instance).
> 2) In the future, there is likely to be more than one type of CellML
> tool available. As long as they all follow the standardised interface
> for the CellML context, the tools will be able to interoperate (for
> example, in the future there could be CellML Context aware command line
> tools, or tools which perform very domain specific operations).
>> As I understand it, pcenv should be a standalone application for people
>> to run. Why does it need to start up a independent server of any kind
>>
> PCEnv is a standalone application, but it comes bundled with its
> dependencies, one of which is cellml_corba_server. CellML CORBA server
> is a shared component which can also be used by products other than PCEnv.
>> and why does it then leave that server running once you exit the
>> application?
>>
> 1) We don't currently have any way of keeping track of who is using it.
> There could potentially be more than one app using the same
> cellml_corba_server, so if it was to exit, there would need to be some
> sort of reference count (this is doable, but see below for why it isn't
> a good idea).
> 2) The user can currently close the PCEnv main window, and then start it
> again and come back to the models they have already loaded, without
> having to wait for CellML CORBA server to start up, and without having
> to re-load their models. This mode of operation will be even more
> important when we get some context-aware command-line tools, as the user
> will expect that the command line program exits immediately, but
> obviously the effects on the context have to persist.
>
> The default configuration for the server is to bind to localhost only,
> so there are no issues of programs on other computers getting access to
> the models you are working on (although this could easily be enabled in
> the future if we need it, presumably with some security interceptors to
> check access).
>
> The only time this should affect the user is when they install a new
> version (I could try to get the Windows installer to kill the process,
> which could help).
>
> Best regards,
> Andrew
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] pcenv and cellml_corba_server, David Nickerson, 10/20/2006
  • [cellml-discussion] pcenv and cellml_corba_server, Andrew Miller, 10/20/2006
    • [cellml-discussion] pcenv and cellml_corba_server, David Nickerson, 10/20/2006
      • [cellml-discussion] pcenv and cellml_corba_server, Andrew Miller, 10/20/2006
        • [cellml-discussion] pcenv and cellml_corba_server, David Nickerson, 10/20/2006
          • [cellml-discussion] pcenv and cellml_corba_server, Andrew Miller, 10/24/2006

---

Archive powered by MHonArc 2.6.18.