Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller wrote:
> David Nickerson wrote:
>> 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.
>>
> This could be better documented (Alan Garny was keen for there to be a
> tutorial, and this could be explained there).

documentation will always help...

>> 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.
> I don't think the average user cares much about how PCEnv /
> cellml_corba_server work internally, so it is better to hide the details
> from them (which is why we ship all dependencies with PCEnv).
> Documenting what happens if they run two instances simultaneously could
> be useful (although this is probably quite an advanced feature, so it
> shouldn't be very high on the list of things in the tutorial).

But users are being forced to care about how this stuff works. If I have
two instances of pcenv running and I happen to want to run simulations
using the same model in both of them then what I do in one will
automatically affect the other - with no user input at all with the user
being totally ignorant of the fact that a single model instance is being
used behind the scenes in both pcenv instances.

>> 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
> Some sort of versioning mechanism could be a useful thing to have at
> some point, although it doesn't really matter until we have more than
> one thing which depends on it.

except that different versions of pcenv itself are already incompatible
with a running cellml_corba_server. Seems versioning would already be
useful.

>> 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.
> The less you bother the user about things irrelevant to them, the
> better. Advanced users who want to debug what is happening can already
> do that, just set the ORBtraceLevel=500 in the environment.

The point I am trying to make is that currently pcenv initiates a server
process that persists beyond the lifetime of the application without in
any way informing the user that this process exists. This seems
incredibly bad to me - what kind of assurance do users have that this
server can't be accessed and used to mess up their system? What happens
on a multi-user machine when I am working on my top secret model that I
don't want to share with my co-workers (for some obscure reason) - can
they access my cellml_corba_server when they run pcenv and hence not
only see my model but be able to change it while I am using it? With any
application I expect that when I quit it, it will stop running and not
leave anything behind.

The fact that a cellml_corba_server is running in the background and
that all models are sitting in this server as a common store of model
instances for all applications that can access that server is in no way
irrelevant to the users of pcenv.

>> 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).
> That would probably make a typical user go and look for other software,
> because it is too much hassle.
>> 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.
>>
> Why go to all this work just to make things harder for the user? What is
> wrong with the current approach (aside from the current issue with
> having to manually stop the server if you install a new version without
> restarting, which could be fixed in much easier ways, like killing the
> process from the installer)?

we need to go to all this work because of the use of
cellml_corba_server. If pcenv truly was a standalone application then
none of this would be an issue. As long as we are going with this
approach of some kind of backend server that persists on the machine
outside of the application run time and using common model instances
shared between applications and multiple instances of the same
application then this needs to be made clear to the user. Sure,
documentation will help, but I don't think that is enough.

If you think making the user start the server process is too much work
for the user, then you can have pcenv provide a nice dialog that has a
big button the user can click to start the server - as long as the user
is explicitly doing something to start the server and is informed that
the server will be persisting until it is explicitly terminated.

The simple fact is that cellml_corba_server and pcenv are two completely
distinct pieces of software. If the cellml_corba_server only lasted the
lifetime of the particular pcenv instance that initiated it and was not
accessible to any other processes, then I would be happy for it to be
buried within pcenv. Given the way cellml_corba_server is intended to be
used it seems, to me at least, to strongly suggest that it should be
distributed as a separate piece of software and executed as such.

---

• [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.