SAMPY undocumented features
luigi at lambrate.inaf.it
Fri Jul 4 06:55:56 PDT 2008
> Hi Luigi,
> Congratulations on creating SAMPY - I'm sure it will be very useful to
> the community.
Hi John, thanks.
I hope it will be useful. Anyway it has been done mainly for prototyping
MIMA. Python is a good language for prototyping, but when one needs
something with good performances, probably what s/he really needs is
something written in Java (Mark's implementation for instance) or in a
compiled language like C/C++. As a matter of fact, I think that the
client toolkit is potentially more useful to the community.
> Regarding your multi-user use case, I don't pretend to fully understand
> it but here's some questions and suggestions.
> 1) You have several users, but they must all log into the machine using
> the same username? Presumably there's some good reason for why you
> can't just assign different usernames to your users?
Because it is easier. Such machine might be accessed by a number of
users, and we don't want to multiply the authorization and configuration
Furthermore, at least in principle, a hub instance (in multi-instance
mode) might also be accessed remotely, without actually performing an
ssh access to the physical machine. It is quite simple to spawn
multi-instance hubs using a proxy app daemon which is running owned by a
service UNIX user. A remote hub could be used to launch (using a
suitable client) the reduction suite, exploiting an activation service
like those available in DBus, CORBA and Ice, for instance. Anyway we are
still working on this stuff and the path is still long...
> 2) If you are are using your own custom mtypes, there's no reason why
> you couldn't pass a username parameter to disambiguate your users (and
> run a single hub). You could have simple proxy apps that sit between
> the hub and your actual datareduction programs to spawns instances as
Yes, actually that was one of the options. Anyway we cannot be sure that
in the future we won't even use standard mtypes, perhaps in order to
communicate with external tools that support SAMP, and such a proxy, at
first glance, looks to complicate a bit things. Multi-instance hubs I
think is a simple and clean solution. Furthermore the multi-instance
paradigm is closer to what happens in DBus (so far we used it), where
you have a single system bus (which could be the normal single-instance
hub) and you can have also multiple session buses (a multi-instance hub
is quite similar to a session bus).
> Keep up the good work,
More information about the apps-samp