Chronological Thread 

< Chronological >      < Thread >

---

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).
> 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).
> 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.
> 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.
> 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)?
>
> David.
>

---

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