Callable clients mandatory operations

[Luigi Paioro]

Thank you Mark,

practical use-cases are always convincing. My proposal came from my 
experience and way of using SAMP, but I see that there are different 
ways of using it and good reasons to let it as already is.

Luigi



> Luigi,
>
> for this one, I don't agree.
>
> I believe that the sender is in the best position to decide whether
> a reply is required from a message, not the recipient, and not the
> MType designer.
>
> Using call rather than notification serves (or has the potential to
> serve) at least four distinct purposes:
>
>     1. retrieve a return value, if the MType defines one (often it does not)
>     2. determine whether the recipient has processed the message successfully
>     3. receive details of an error if one has occurred
>     4. delay further relevant processing until receipt has completed
>
> In fact, in my experience it is quite common for MTypes to be used
> by some senders in Call mode and by others in Notification mode,
> often where a message looks like a notification (has no return value)
> but to serve one of the other three purposes above.
>
> Consider the MType table.load.votable.
>
> A simple tool which simply generates a table might want to let
> other clients know that a table is available to load, but not
> really care whether they do so or not.
>
> A more complex tool might want to send a table to a specific
> partner client, and need to know whether it completes so that
> for instance it can inform the user (with human-readable
> error diagnostics) if failure has occurred, or so that it
> can decide to send or not send subsequent table.highlight.row
> messages relating to it.
>
> Even for a logging MType, one can imagine an application that
> wants to use Call mode to determine whether completion is
> successful, so that it can be aware whether the logging
> machinery has broken down, and perhaps notify a user or cease
> operation if logging is considered a critical function.
> I admit that this would not be a common case, but I think
> that the decision about whether it's appropriate is better
> taken by the message sender than by the MType designer.
> Another example is that some middleware might want to
> turn all notifications into calls in order to monitor response times
> (I'm considering adding this as an option into the JSAMP hub).
>
> I admit it's hard to think of a realistic case (except testing)
> in which something like client.env.get would be used in Notify mode,
> but some response-bearing messages might also have side-effects.
>
> As far as the burden on the implementor goes, I don't believe it's
> significant enough to warrant the changes you suggest to the
> existing one-size-fits-all situation.  The mapping between
> receiveNotification and receiveCall is straightforward,
> and is suitable for handling by library code.  For instance in
> JSAMP the most straightforward way to implement handling for
> a given MType is by subclassing a class
> (http://software.astrogrid.org/doc/p/jsamp/1.0/apidocs/index.html)
> and implementing the single method
>
>     abstract Map processCall( HubConnection connection,
>                               String senderId, Message message )
>
> the library then invokes this same method in order to process
> either a call or a notification; it just throws away the return
> value in the latter case.  I think library code in other languages
> should be able to do something similar.
>
> Mark