samp.status=samp.noresponse

[Mark Taylor]

Permanent.  It would be an error to have more than one response to a 
single call, so the hub certainly shouldn't send a samp.noresponse
at one point followed by a response with a different status later.
If there's any chance that a real response might arrive in the
future, the hub should not send a samp.noresponse response.

In the case of the client that unregisters without replying:
if it re-registers it can't supply a response to a message it 
received during its previous period of registration, since 
on re-registering it will have a different client ID, and hence
be as far as the hub and any other clients are concerned a 
different client.

Mark

On Wed, 13 Jul 2011, Jonathan Fay wrote:

> I think it is a good concept.
> 
> One follow-up question. If a client receives a "samp.noresponse" from the hub, could this be a one-shot issue, or could the recipient client come back at some point?
> 
> Put another way; Is it a perminent condition, or a momentary one?
> 
> Jonathan
> 
> ________________________________________
> From: apps-samp-bounces at ivoa.net [apps-samp-bounces at ivoa.net] on behalf of Mark Taylor [m.b.taylor at bristol.ac.uk]
> Sent: Wednesday, July 13, 2011 5:35 AM
> To: apps-samp at ivoa.net
> Subject: samp.status=samp.noresponse
> 
> 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/

--
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/