samp.status=samp.noresponse

[Mark Taylor]

No, that's not what I had in mind.  Some reasons for believing that a
future response will not arrive might suggest that the client in question
is out of action for good, and others might not.  My intention here is
just to allow the hub to generate and pass back a response for a 
single message which will never get a client-generated response.
No further conclusions are implicit in such a response.

On Wed, 13 Jul 2011, Jonathan Fay wrote:

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

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