samp.status=samp.noresponse

[Mark Taylor]

Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
error processing, has the following wording:

  "In the case of failed calls of the operations defined in Sections
   3.11 and 3.12, for instance syntactically invalid parameters or
   communications failures, hubs and clients SHOULD use the usual
   error reporting mechanisms of the transport protocol in use. Note in
   particular that a samp.status=samp.error-type Response (Section 3.9)
   is only generated by a client processing a received Message, it MUST
   NOT be used by the hub to signal a failed call."

I don't remember if there was a strong motivation for this prohibition
on the Hub originating an error Response.  However it occurs to me that
there is at least one circumstance when it would be a good idea for
it to do so: if the hub has determined in some way that a recipient
client is never going to respond to a pending call/response message 
(for instance because the client has unregistered), it would be good 
if it could inform the sender of that fact.  This would prevent the 
sender waiting for ever for a response which will not arrive.
For an asychronous call/response message using the existing API,
the only way that the hub can pass that information to the sender
is using a hub-generated Response; the reporting mechanisms of
the transport protocol (e.g. XML-RPC Faults) can't be used after
the Call has been received, since the RPC for the Call part has finished.

I therefore suggest:

   1. The last sentence of the quote above be removed or replaced.

   2. The possible values for the Response map samp.status key
      defined in section 3.9 be extended: a new value "samp.noresponse",
      intended only for use in Hub-fabricated responses, should be 
      added alongside samp.ok, samp.warning and samp.error.

Item 2 is debatable - it might be better to use the existing samp.error
status for this purpose, since in most cases the sender would want to
treat a no-response as a kind of error, and this would have less 
potential to disrupt existing code, but my feeling is that the 
additional clarity provided by a status specifically intended for 
this situation is worth the (minor) disruption potential.

I've made a provisional edit to the SAMP document along these lines,
see http://code.google.com/p/volute/source/detail?r=1539

If anyone disagrees with the idea or the details, please say so.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/