samp.status=samp.noresponse

[Jonathan Fay]

I meant pertaining to future messages. Should it be implied that a no response means any further attempt to send messages to that recipient would also be fruitless?

Jonathan

-----Original Message-----
From: Mark Taylor [mailto:mbt at star.bris.ac.uk] On Behalf Of Mark Taylor
Sent: Wednesday, July 13, 2011 7:08 AM
To: Jonathan Fay
Cc: apps-samp at ivoa.net
Subject: RE: samp.status=samp.noresponse

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/