SAMP environment variables

[Mark Taylor]

Hi Luigi,

here's what I think; if I've misunderstood your requirements please
say so.

On Tue, 23 Jun 2009, Luigi Paioro wrote:

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

What you want to be able to do is to restrict communications to a 
single defined client.  Your XPA example above does this by assigning
an identifier to the remote client on startup, and using that as
a label for message targetting (I don't know whether this control 
is achieved by the XPA server or by the DS9 client(s); but it 
doesn't really matter for this conversation).

SAMP doesn't lend itself very well to using that model directly, 
but it would work fine the other way around - start the remote 
application, determine its identifier (the SAMP client-id) and use 
that for targetting subsequent communications.  So the problem 
becomes: how do you determine the client-id of a client that
you've just started?  Using environment variables as you suggest
is one possibility (see below for a bit more discussion of this).
But there are other options; one possibility would be to get DS9
to write its title (supplied with the -title flag as above) into
the metadata map it declares to the hub on registration.  You'd
have to wait until you received the corresponding 
samp.hub.event.metadata message before you knew which client it
came from (as you would with the environment variable proposal I think),
which is an extra step, but it would work.  Putting the "title"
or other instance identifier in the declared metadata would be
quite a good thing for clients to do in any case.  Another possibility
is that DS9 could record the client-id it gets assigned in some
non-SAMP-related way that the calling process can access 
(e.g. print it to stdout, or save it to a file), but that 
gets a bit messy.


Considering the use of environment variables as such:

> 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>

If I understand correctly, much the same thing (allowing client A to 
determine the value of environment variables present in the environment
of client B) could be done simply by introducing a new MType, something
like:

   MType:
      client.env.get
   Arguments:
      name (string) - environment variable name
   Return values:
      value (string) - value of env variable "name" in receiver's environment

This would require no changes to the standard, and no special 
environment variable name syntax rules.  Since subscription to this
MType would (like any other MType) not be compulsory, one couldn't
guarantee that a given client would support it, but client toolkits
might be expected to support it by default if it became semi-official,
so it needn't place much burden on client implementors.
 
Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/