Callable clients mandatory operations

[Luigi Paioro]

Dear All,

with this e-mail I propose you a second change/improvement to the SAMP 
protocol, submitting it to your evaluation. In this case I start from a 
real use case:

I have a service application (named Logger) that receives logging 
messages from the other applications, and store them in a file or database.

Logger subscribes to logging.* messages in order to receive these MTypes:

   logging.critical
   logging.error
   logging.warning
   logging.info
   logging.debug

all accepting these parameters:

   origin: a string with the name of the program origin of the message
   message: the logging message content


Logger is a very simple application, being callable just to receive the 
logging messages notifications, and nothing more. Implementing it with 
SAMPy pythonic API I just wrote the single function used to handle the 
notification messages and bound it to the SAMP client instance. However, 
if I had to implement a client from scratch I would have to implement 
two functions, one mapping the receiveNotification operation and another 
(useless) mapping the receiveCall operation. This because the protocol 
specifies that either operations MUST be implemented.

On the other hand there is no way to distinguish a priori whether an 
MType is supposed to be used for events notification or a call, and in 
principle I might use, e.g., logging.info for a call. In my opinion this 
is an excess of freedom in the protocol considering that, in practice, 
the MTypes are always defined thinking to an event-MType or call-MType 
(at least this is my experience). I have never seen (so far) MTypes used 
for notifications and calls at the same time. And actually only those 
MType not returning a response parameter set can be reasonably used for 
notifications.

Thus:

- on one hand the protocol obliges the client implementors to support 
either calls and notifications, even if only one of them is really needed;
- and on the other hand we have MTypes that are implicitly supposed to 
be use for calls only (or events only), but this is not clearly stated.

So this is my proposal in two points:

1. add to the MType a Scope ("call" or "event"). This can be just an 
entry in the wiki page (and in SAMP document for the administrative 
MTypes), as for "Arguments", "Return Values", "Description". Optionally 
an additional "samp.scope" = "call" | "event" could be added to the SAMP 
messages (as for "samp.mtype" and "samp.params"); this could be useful 
for a preliminary check of the messages by the Hub.

2. allow the clients to implement AT LEAST one of the two operations 
that a callable client MUST support, and not necessarily both.


The two point here above should grant the backward compatibility of the 
protocol itself and of the software that already exists.

Thanks in advance for any comment or opinion.

Regards,

   Luigi


-- 

Luigi Paioro

INAF - IASF Milano
Via Bassini 15, I-20133 Milano, Italy

Phone  (+39) 02 23 699 470
Fax    (+39) 02 26 660 17
Site   http://cosmos.iasf-milano.inaf.it/luigi/