samp.status=samp.noresponse

[Mark Taylor]

Luigi,

I'd resist declaring a well-known samp.errortxt value, since that 
should probably be free text, and in any case it may be useful to 
inform the user exactly what's happened (client has unregistered, 
message state discarded because of hub memory limits, something else...).

A well-known samp.code for this purpose as you suggest would however 
do the trick, and is fully backward compatible.  It feels a little bit
untidy to me, but it's not a bad idea.

Since the samp.status entry is declared as an extensible vocabulary,
client code ought to be prepared to deal with values other than
samp.ok, samp.warning and samp.error.  However, I agree, in practice
it's possible that it won't.  Do you (or anybody else) have a feeling
for whether this is likely to cause problems for existing code
in practice?

Mark

On Wed, 13 Jul 2011, Luigi Paioro wrote:

> This is a good point, and from a general point of view probably the option 2
> is preferable, but, as you say, it could raise some problem in existing code
> (not able to recognize samp.noresponse key). I'm a bit concerned about this
> issue. A possible option could be to return a samp.error with a well know
> samp.code and samp.errortxt. I cannot figure out another backward compatible
> solution.
> 
> Luigi
> 
> 
> Il 07/13/11 14:35, Mark Taylor ha scritto:
> > 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/