SAMP environment variables

[Mark Taylor]

On Tue, 23 Jun 2009, Luigi Paioro wrote:

> > 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.
> 
> Having an environment variable, the current applications communicating via
> SAMP exploiting the client toolkits (and thus not only DS9) would inherit this
> feature without being directly touched (once the client toolkits are updated
> in order to support this feature). It is a proposal starting from a specific
> case but that, I think, can be of general interest.

that's true.  However, note that your existing XPA solution only 
works with explicit cooperation from the application in question -
DS9 has to understand the -title flag in order for the XPA-based
targetting scheme that you describe to work, so you're proposing
for SAMP something over and above the current capabilities of XPA.

> > 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.
> 
> 
> This is a very nice alternative. My only concern is that this MType would
> allow the requester to access whatever environment variable seen by the
> client. I think it is not a safe approach, especially thinking to a
> distributed environment. I cannot give you a real example, but I have this
> feeling. A possible workaround is limiting the environment variables this
> MType can return to only those with a prefix SAMP_.

I hadn't thought of that.  Anybody with a SAMP connection to a hub
which you're connected to already has the potential to do harmful
things (for instance load unwanted images into your image viewer),
so the scenarios I've been thinking of assume that connected clients
are reasonably trusted (it's why the samp.secret is present in a 
user-only-read file in the lockfile).  However I know that you've
been thinking of more distributed scenarios, so there may be some
important issues here.  Restricting accessible variables by namespace
would be possible in any case (though the MType definition gets
a bit more messy).

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/