SAMP environment variables

Luigi Paioro luigi at lambrate.inaf.it
Tue Jun 23 05:28:54 PDT 2009


Dear SAMPers,

   the PANDORA team is planning to restyle the software produced so far 
in order to include, along with the other things, a complete support to 
SAMP.

In particular we would use SAMP as a replacement of XPA, the messaging 
system used within VIPGI in order to drive DS9 as external graphical 
component. Nonetheless I see a problem that I'd like to discuss with you.

When VIPGI needs to display a FITS image it spawns a ds9 process 
assigning a conventional title with a command like this:

$ ds9 -xpa yes -title VIPGI_FG_01

then, all the following interactions are performed using XPA commands 
specifying the target DS9 instance through the assigned title, e.g.:

$ xpaset -p VIPGI_FG_01 file VIMOS.2008-11-02T02:52:16.963.fits

VIPGI has a direct control over the process spawned and the process to 
communicate with (that is the title). I can have several VIPGI processes 
and each VIPGI process can spawn several DS9 sub-process, but, dealing 
with different DS9 titles, there are no communication conflicts or 
ambiguities.

This paradigm cannot be followed with SAMP as defined now. There is a 
missing concept, that is the possibility to assign a priori a label to a 
certain SAMP client and use this label to recognize the client I really 
want to communicate with.

A possible workaround that preserves a complete backward compatibility 
with the present SAMP specification could be the introduction of an 
environment variable, say SAMP_APP_LABEL or whatever, which is 
recognized by the application (or the client toolkit) and made 
accessible as a metadata keyword (e.g. "samp.app.label") and/or as the 
value returned by client administrative message (e.g. an MType 
"samp.app.label").

In principle one might think to create a general mechanism that allows 
to transform a SAMP environment variable to a metadata. For example, any 
environment variable of type:

SAMP_<word 1>_<word 2>_<word n>

is mapped to a metadata k/w

samp.<word 1>.<word 2>.<word n>

In this way it would be possible to define any number of custom metadata 
k/w manually set by the end-user (which, in my case, is VIPGI).

What do you think about this proposal?


With my best regards,

   Luigi


-- 

Luigi Paioro

INAF - IASF Milano
Via Bassini 15, I-20133 Milano, Italy

Phone  (+39) 02 23 699 470
Fax    (+39) 02 26 660 17
Site   http://cosmos.iasf-milano.inaf.it/luigi/



More information about the apps-samp mailing list