SAMP environment variables

[Luigi Paioro]

Hi Mark,

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

Yes, right!


> 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

Yes, this is the question.

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


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


Luigi