Re: [Chimera-users] non-GUI use of Chimera
Hi, I am working with Randy on this, and I think we have a web service type solution that will work using your suggestions. The one problem that remains is killing chimera after a request. The webdata facility is targeted to run on a client's machine where a user quits chimera, but we will be running it on the server. I tried adding the 'stop' command at the end of the chimerax file, but I received an error from chimera and it continued to run. Same story for 'sys.exit()' Running the chimera_send script a second time only opens a new instance of chimera which also remains open. Is there a way to attach chimera_send to an existing process of chimera, or have chimera quit at the end of a chimera_send call? Thanks, Charlie
-----Original Message----- From: chimera-users-bounces@cgl.ucsf.edu [mailto:chimera-users-bounces@cgl.ucsf.edu] On Behalf Of Thomas Goddard Sent: Monday, May 24, 2004 6:20 PM To: heiland@indiana.edju Cc: chimera-users@cgl.ucsf.edu Subject: [Chimera-users] non-GUI use of Chimera
Hi Randy,
If I understand correctly you want to be able to type some Chimera Python code or Chimera commands to a web browser, those get sent to the web server which sends them to Chimera running on the web server machine. Then you capture the Chimera image and send it back to the web browser.
I believe this can be done using the Chimera "Web Data" facility. This allows programs to send commands to Chimera. The intended use is for displaying models in Chimera when the user clicks a link in a web browser. It works by having the *.chimerax file associated with the link lauch helper application <chimera-install-location>/bin/chimera_send. The same mechanism allows any program to send commands to Chimera. The Chimera User's Guide describes this under Tools/Web Browser Configuration. Here's a URL:
http://www.cgl.ucsf.edu/chimera/1.1951/docs/ContributedSoftware/webdata/ chimerax.html
What you might do is have your web server create an appropriate *.chimerax that executes the user's commands and then prints the Chimera graphics window to a file. The web server than sends the image (jpg) to the web client. There is a bunch of somewhat tricky glue to make this work. As previous posts mentioned, Chimera will need to pop up windows on some screen to render an image. For the web server to know when Chimera has finished making an image, the *.chimerax file might end in a command that writes to some secondary status file after the image file is written. That will tell the web server that the image is ready.
We haven't tried this. And there are other pitfalls, like you are likely to run into trouble if the web server starts 2 instances of Chimera and then tries to dispatch commands with the chimera_send program.
Please let me know if you get this to work. Feel free to send additional questions.
Tom _______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Hi Charlie, You should be able to use sys.exit() in a *.chimerax script to quit Chimera. The sys.exit() call raises SystemExit. Unfortunately the code that runs the *.chimerax file is catching the SystemExit. This is a bug in Chimera 1951 that we will fix. For now you can use "import os" and "os._exit(0)". The chimera_send script will start a new Chimera if it does not find one already running that is accepting connections. By default Chimera does not accept connections. The easiest way to change this is to start Chimera by hand and use Favorites/Preferences/Web Data to turn on "Accept Web Data". Then press the Preferences Save button to save this setting in the user's Chimera preferences file (~/.chimera/preferences). (Note you'll need to do this as the user that Chimera runs with from the web server.) You can also change the "Confirm open of commands or code" preference to "never". This will prevent the Chimera warning dialog asking whether you really want to execute the *.chimerax file. You can also save this setting. Making these settings may pose a serious security risk. There are mechanisms to allow only the same user that is running Chimera to run *.chimerax files but I do not know how strong the security is. Dan Greenblatt (dan@cgl.ucsf.edu) wrote the code and would know. As it works now, if you wish to send commands to an already running Chimera, you cannot specify which instance of Chimera. So it is not possible to communicate with multiple instances of Chimera as you might want to support multiple web sessions. Dan Greenblatt may have ideas for addressing this. Tom
We do not need the ability to issue requests to a specific instance of chimera. I changed the preferences and I was having new instances of chimera appear for each request, but that changed after restarting chimera. The current solution we are using involves the following. You open a web page which is a python/cgi script that prompts for input. Using SOAPpy, we issue a call to a web service function to do the rendering. The SOAP response is a pointer to the image url. The SOAP server just generates a chimerax file based on the request and spawns a chimera_send process. Other than the fact that we must have chimera attached to an Xserver everything works really well. Thanks, Charlie Thomas Goddard wrote:
Hi Charlie,
You should be able to use sys.exit() in a *.chimerax script to quit Chimera. The sys.exit() call raises SystemExit. Unfortunately the code that runs the *.chimerax file is catching the SystemExit. This is a bug in Chimera 1951 that we will fix. For now you can use "import os" and "os._exit(0)".
The chimera_send script will start a new Chimera if it does not find one already running that is accepting connections. By default Chimera does not accept connections. The easiest way to change this is to start Chimera by hand and use Favorites/Preferences/Web Data to turn on "Accept Web Data". Then press the Preferences Save button to save this setting in the user's Chimera preferences file (~/.chimera/preferences). (Note you'll need to do this as the user that Chimera runs with from the web server.) You can also change the "Confirm open of commands or code" preference to "never". This will prevent the Chimera warning dialog asking whether you really want to execute the *.chimerax file. You can also save this setting. Making these settings may pose a serious security risk. There are mechanisms to allow only the same user that is running Chimera to run *.chimerax files but I do not know how strong the security is. Dan Greenblatt (dan@cgl.ucsf.edu) wrote the code and would know.
As it works now, if you wish to send commands to an already running Chimera, you cannot specify which instance of Chimera. So it is not possible to communicate with multiple instances of Chimera as you might want to support multiple web sessions. Dan Greenblatt may have ideas for addressing this.
Tom
Hi Charlie, Can I try your Chimera web interface? It's a neat idea that we may have other uses for. I don't understand how your web server can handle multiple simultaneous requests that require Chimera rendering. If you send the requests to one instance of Chimera that you keep running it is possible that a request will get received in the middle of processing some earlier request causing havoc. Tom
Hi Charles, If you do want to support multiple users and simultaneously running instances of Chimera, you'd need to control who gets the request coming from the chimera_send script. To do this, you'd need to dynamically rewrite the 'rendezvous' file where chimera_send looks to see who's listening. This is located usually in /tmp/chim_webinfo-<USERNAME > where <USERNAME> is the name of the user running Chimera (from the USER environment variable). This file is only in existence while there is an instance of Chimera running on the machine, and it is listening for data. Multiple users on the same system can be running Chimera, each user would have their own corresponding file. The file is user-read-write only. The first line contains three keys that are used for security purposes (each client attempting to send information to Chimera must correctly identify these keys), and each of the following lines contains information in the format port,pid where pid is the process id of a running Chimera, and port is the port number that that instance of Chimera is listening on. chimera_send will send the request to the most recently registered instance of Chimera, i.e. the one at the bottom of the list. So if the /tmp/chim_webinfo-cmoad file looks like: 43245,787727,838545 4576,98543 2567,98550 3879,98556 chimera_send will send the request to the instance of Chimera with pid 98556, listening on port 3879 . Note, the original intent here is for a user to have multiple instances of Chimera running on their desktop, and for them to be able to determine which Chimera will receive the file from a web browser, by raising a particular Chimera window above the others. Each time you raise a Chimera window by giving it the focus, that instance rewrites the rendezvous file to put itself first (i.e. last in the list). You could mimic this behavior programmatically by rewriting this file from the server-side CGI script depending on where the request came from. Hope this helps! -Dan On Tuesday, May 25, 2004, at 01:58 PM, Thomas Goddard wrote:
Hi Charlie,
Can I try your Chimera web interface? It's a neat idea that we may have other uses for.
I don't understand how your web server can handle multiple simultaneous requests that require Chimera rendering. If you send the requests to one instance of Chimera that you keep running it is possible that a request will get received in the middle of processing some earlier request causing havoc.
Tom _______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
If I start it remotely it cannot do the on screen rendering, so I will start it in the morning and send you a link. The SOAPpy.SOAPServer that I use to handle requests only handles one at a time. I could have it spawn new processes/threads. I would think that spawning threads to handle simultaneous requests would work if you have the preferences set to not listen for web data. This would spawn new independent instances of chimera for each request. One may ask why not have the python/cgi script spawn the process directly and cut out the web service. I tried this and found out from others who have tried similar things, apache does not like to spawn new processes from the cgi-bin. They usually just return an error code. Also allowing the apache user access to the Xserver and chimera is difficult. The SOAP code is VERY simple however. - Charlie On May 25, 2004, at 3:58 PM, Thomas Goddard wrote:
Hi Charlie,
Can I try your Chimera web interface? It's a neat idea that we may have other uses for.
I don't understand how your web server can handle multiple simultaneous requests that require Chimera rendering. If you send the requests to one instance of Chimera that you keep running it is possible that a request will get received in the middle of processing some earlier request causing havoc.
Tom
participants (3)
-
Charles Moad -
Daniel Greenblatt -
Thomas Goddard