SAMPY undocumented features

[Luigi Paioro]

Hi Mark!

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

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.

Yep...

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


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

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


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


Ciao,

   Luigi