SAMPY undocumented features

[Mark Taylor]

Luigi,

On Thu, 3 Jul 2008, Luigi Paioro wrote:

> In this mail I will show you these advanced capabilities, so that you can try 
> to use them (if you need them) or in case just comment whether they are 
> really useful within the context of SAMP or not (I hope the former).
>
> To outline better the reasons of these additional capabilities, let me show 
> you our practical use case (or scenario). We have a server machine which is 
> the sole host that has a set of data reduction programs installed. Whoever 
> wants to use this reduction suite must login to this host with a specific 
> user (the only provided with the right authorizations).
>
> The different components of this reduction suite should communicate one with 
> another using SAMP. The problem is that if more than one user are logged in 
> at the same time, they connect with the same Hub sharing all the different 
> client instances of the reduction suite... and we don't want this.
>
> Then I've introduced a multi-instance starting mode, that is a way to allow
> multiple Hub instances running at the same time. In practice you launch
> SAMPY in multi-instance mode typing:
> 
> $ sampy.py --multi
> 
> 
> What SAMPY does is to check whether the directory $HOME/.samp-1 exists
> ($HOME or %USERPROFILE%) and if it doesn't then SAMPY creates it (.samp-1
> means SAMP version 1). Then SAMPY starts a new Hub with a
> 
> $HOME/.samp-1/samp-hub-<PID>-<ID>
> 
> lock-file. <PID> is the process ID of the program that holds this Hub, and
> <ID> is an integer indicating an additional Hub ID for those programs which
> are able to spawn multiple Hubs (in my case it is a thread number).

The extensions you've proposed to how your particular hub implementation
operates seem fine (also your optional hub timeout parameter).

> From the Hub side that's all. The clients, if not specified, try to connect
> with the single instance mode Hub (looking for $HOME/.samp lock-file).
> Otherwise, if specified, clients look for all the available Hubs (looking
> for $HOME/.samp and $HOME/.samp-1/samp-hub-* lock files), ask to the user
> which one s/he wants to connect with, and then they perform the connection.

I'm a bit concerned about the client operation however.  The behaviour
demanded from clients in the hub discovery phase is now different,
and more complicated, than that currently specified in the Standard
Profile part of the SAMP document.  I'm not sure exactly what you're
suggesting here, is it

    a) This altered hub discovery prescription will be used only by
       clients/hubs specific to the MIMA FASE environment (effectively
       defining a new Profile similar, but not identical to, the
       Standard Profile)
          - that would work OK, but it means that applications written
            only to conform to the Standard Profile written in the
            SAMP document will not be usable from this environment
            since they would look for the hub in the wrong place.
            This lack of interoperability seems like a bit of a shame,
            though depending on FASE's particular requirements maybe
            it doesn't really matter.

or

    b) You are proposing to extend the Standard Profile definition so
       that hub discovery works like this rather than as currently
       written.
          - I'm concerned that this makes it quite a bit more complicated
            for clients to implement than the existing prescription -
            especially the "ask the user which one s/he wants to
            interact with" part which effectively requires each application
            to invent and document some new user interaction.

In any case, I think I understand your requirements and they look 
reasonable - although the current SAMP document is phrased in terms 
of one hub per user per host with everything running on the same host 
it's been in the back of our minds that it ought to be possible 
to extend the framework to other scenarios in some way, though 
we (or at least I) have not given much thought to how this might work.

Clearly a single lockfile in a well-known per-user location of the
form we've written in the existing document won't work for your
multiple hubs per user per host scenario.
However, as I've indicated above I'm not totally convinced by the
details of the client-side procedure that SAMPY uses.
Getting the hub to write lockfiles in custom places according to 
implementation is OK, since the user can select which hub to use
for their particular requirements, but requiring the clients to look
in undocumented places is not, because clients may have been written
by third parties who did not know about the undocumented conventions.

So the question arises of how to tell clients where to find the hub.
The most straightforward way I can think of to do this is by using
environment variables.  Instead of simply looking in home-directory/.samp
for the lockfile we could say that

   1. if an environment variable SAMP_HUBFILE exists, use its contents
      as the location of a hub lockfile
   2. otherwise, the location of the hub lockfile is home-directory/.samp

Another possibility would be to pass hub discovery information directly
in environment variables (e.g. SAMP_SECRET, SAMP_HUB_XMLRPC_URL etc)

I'd be interested to know whether you think this would solve your 
use case, and your and anyone else's opinion
on whether this looks like a sensible way to go for generalising hub discovery, 
or whether Luigi's $HOME/.samp-1/samp-hub-* scheme is preferred, 
or whether we shouldn't be thinking about generalising hub discovery,
or whether anyone has a better idea.

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/