Chronological Thread 

< Chronological >      < Thread >

---

Note: This e-mail replies to several mails by David Nickerson and Alan
Garny.

David Nickerson wrote:
> 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.
>
Models are frozen once they are integrated, which means that you can
only change a copy of the model, not the original. The user is asked if
they want to clone the model if they try to change a model which has
been frozen.
>
>>> 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.
>
We haven't made any stable releases yet. Snapshots don't really need to
be compatible with each other (after all, they are not guaranteed even
to work, as they get built and released automatically, without any QA on
them at all).
>
>>> 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 is a very common design pattern. e.g.
Running any KDE app starts up DCOP servers (if they aren't already
running).
Running a Win32 program in wine starts up wineserver so the clipboard
will work.
Installing MSVC on Win32 also installs mspdbsrv, a server which loads
at startup and stores debugging information for the compiler.
Many instant messaging and e-mail programs remain open after the user
closes the main window so they can monitor for new messages.
Almost all Mac OSX / Carbon applications remain running but idle after
the main window is closed, so that they can start up again faster the
next time.
VMWare Player installs startup scripts for many backend processes,
which run even when the player has exited.
> 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?
The CellML DOM API does not write any files, except bootstrap IOR
locations once at startup, temporary files (which follow best practices
for safely allocating temporary files). It is unlikely that any of these
operations could mess up the 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
I assume that in this situation, you would be using a different user
account to the co-workers. Just running PCEnv isn't enough, because the
IOR file describing how to find the server is stored in a user-specific
directory. However, it wouldn't be that hard to guess the IOR using data
from commands like netstat -l.

On *nix, I have fixed the issue of multi-user machines by switching to
mode 0700 Unix domain sockets. With the latest snapshot, you need to be
the same user (or be root) as the cellml_corba_server in order to be
able to access it.

On Win32, any local user can theoretically access the server (although
this wouldn't happen automatically if you started PCEnv, you would have
to do some work to guess the IOR). However, there are many other ways to
get at a process on a Win32 system, so having to trust other local
processes is common practice on Win32 (i.e. you shouldn't be giving
anyone shell access to a Win32 box if you are doing anything on it you
don't want them to see). If it is a really big issue, we could write a
patch for omniORB to make it use Windows pipes for the equivalent of
giop:unix: transports.
> 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.
>
See the list above. Lots of applications leave background processes
behind. Of course, it might be good to have a way to exit the background
process (perhaps a tray icon?), but the ways of doing this differ
between platforms.
> 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.
>
It certainly provides useful functionality to the user, but I don't
think it is especially surprising that it works that way, especially not
if we mention it in the manual. After all, filesystems work this way,
its not like you have a separate independent filesystem for each
process, and so us
> 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.
>
>
KDE apps don't explicitly ask you if you want to start the DCOM server,
wine doesn't ask you if it can start wineserver. The only documentation
about MSPDBSRV at all
(http://search.msdn.microsoft.com/search/default.aspx?siteId=0&tab=0&query=MSPDBSRV)

is that if you get certain warnings it may be missing (other than that,
official docs don't even mention it). I don't think there is any
precedent to making things so hard for the user over this.

> 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.
>
We distribute lots of things together with PCEnv, because it is supposed
to work out of the box (basically, everything that we need to run on a
clean system).

> I grabbed the updated 20061020 snapshot and I am now able to load my
> model and run an integration and get the results I would expect over the
> default 10ms interval. However, if I try to change any of the
> integration parameters and then click integrate I just get a bunch of
> RDF looking errors in the javascript console. This also seems to kill
> the cellml_corba_server and I need to exit and restart to continue.

I have tried with a model which has graph and simulation metadata
already in it (on a clean Ubuntu Dapper virtual machine, with the latest
PCEnv snapshot), and with a model which just has the cmeta metadata, and
both let me change the initial conditions and integrate the model. It
sounds like the issue is limited to one particular model. Could you
please send me the model which triggers this problem?

> Anyway, being able to run even the 10ms gave me a bit to play around
> with in terms of the graphing interface which seemed to at least work
> and I was able to draw some graphs. I'm guessing some documentation on
> how to use the various widgets might help unravel the usability of the
> interface. I should probably reserve further comment until I get to play
> with some more complete simulation results...

You have found the manual I presume? (Help => Manual from in the GUI).

> In general, from the little I am able to currently use, the interface
> seems a bit non-obvious...but thats probably true of most new
> applications. A nice illustrated step-by-step guide would probably be
> very useful - just something simple to start with: load a model, set
> integration interval, integrate, and plot. Then re-run the same
> simulation after changing a parameter and plotting the results together.

I agree we should have a tutorial. However, I'm not sure that it needs
to be illustrated (at least not until the release comes out). The
problem with including lots of screenshots in a tutorial is that every
time you make even a minor change to the UI, your images are out of date.

Alan Garny wrote:

> I have done the same (get the 20 Oct snapshot) for both Win32 and Linux.
> Again, I have installed each version in a clean environment under VMWare.
> The Win32 version started fine, but they if I try to open a CellML file,
> nothing happens (and nothing is reported in the javascript console).

I will have to try the Win32 issue soon (I don't yet have a Win32 VMWare
environment set up yet, so the best I can do is test as another user on
the Win32 build system, which worked correctly for me).

>
> The Linux version started fine too and I was able to open one of my CellML
> files, but when trying to run it (using all the default settings), it
> complained about the same thing as before, that "integration failed: could
> not compile the model code."


I think this is due to the missing math.h issue that I have fixed today
(this is in the latest snapshot already). I tested this on a clean
Ubuntu Dapper install (in VMWare), which has no compiler installed.

Best regards,
Andrew

---

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