SAMPY undocumented features
luigi at lambrate.inaf.it
Tue Jul 8 05:58:03 PDT 2008
> 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.
> b) You are proposing to extend the Standard Profile definition so
> that hub discovery works like this rather than as currently
> - 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.
I'd like to discuss about b) and, in case, about a). A possible middle
way is to foresee a basic hub/client behaviour (single hub and .samp
lock-file) and an advanced hub/client behaviour (multiple hubs and ...
whatever) in the Standard Profile, stating that the Basic Standard
Profile support is mandatory for hub/client developers, while the
Advanced Standard Profile support is optional. Thus, "ASP" clients are
able to talk with "ASP" clients and with "BSP" clients, while "BSP"
clients are able to talk with "BSP" clients and with "ASP" clients which
are running using a basic profile. Honestly, whether this means that I'm
suggesting to have another optional profile or to extend the standard
one is not clear even to me...
> 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.
This undocumented place should be such only for the time being, until it
is not standardised.
> 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
This looks to be a good alternative and 1. actually is the solution
adopted by the DBus community (more or less). It works well, but there
are a couple of issues:
1. As far as I know an environment variable can be set only within a
run-time process, that is it cannot be exported. So, when you launch a
samp-hub daemon which set up the environment variables, such variables
are valid only inside that process. A way to overcome this issue is to
find a way to directly call the "setenv", "export" or whatever built-in
shell function (which are even OS dependant). The DBus workaround is
that dbus-launch program, once launched a session bus (the equivalent of
a samp hub) prints out the values of the environment variable that
should be manually set at shell level (check it out). A workaround to
the workaround is to wrap dbus-launch with a bash program that parses
the result of dbus-launch and calls export, setenv, etc... and this is
what happens at Linux start-up level (more or less).
2. Supposing that 1. is not an issue, then you can have only one hub
reachable per terminal (shell), since the environment variable are valid
only inside the terminal process (for the same reasons above). If an
application running on a S1 shell wants to connect with the hub started
in shell S2, then I must setup manually the SAMP env. variables reading
them from S2 and copying them in S1. I did it for DBus and it was really
boring. Then I wrapped dbus-launch with a bash program that wrote down
the connection information in files like those proposed for SAMP, and I
also coded a client tool-kit that simplified things. I didn't find a
> 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
> or whether anyone has a better idea.
$HOME/.samp-1/samp-hub-* scheme is not perfect and does not simplifies
client developers' life, this is sure. For instance, a problem with this
scheme is that if a hub dies then its lock-file remains there forever.
I'm still convinced it is a reasonable solution, but I'm also sure that
with your (you and the mailing list) contribution it can be certainly
A general comment. It is sensible to keep as simple as possible the
client side in SAMP, but however simple it could be I think that SAMP
will be widely adopted only if the SAMP community will be able to
provide a large set of client toolkits, at least for all the most common
One year ago I tried to talk about PLASTIC and DBus/MIMA to my
colleagues which are a little astronomers and a little developers
(mainly astronomers). Talking about PLASTIC, I must say that it was
quite difficult to convince them that the creation of an XML-RPC
connection with a PLASTIC hub or the creation an XML-RPC server for
client purposes and the related stuff wasn't so hard to do as it seemed
(even in Python). Well, as a result I had to implement a Python PLASTIC
module that simplified even more those operations (perhaps you remember
PYSTIC). A very simple client API specific for Python developers was
much more charming for them, and it was adopted (even if for small things).
Said this, I think that we could complicate a bit SAMP at client level
without worry too much, as long as the SAMP community is willing to
produce client libraries (modules, packages or whatever) for different
languages, that can be used by the broader community to easily interface
their applications, scripts, programs or whatever with a SAMP Hub.
More information about the apps-samp