SAMPY undocumented features

[Luigi Paioro]

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

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

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,
> 
> John

Thanks again.

Luigi