samp.status=samp.noresponse

[Mark Taylor]

Luigi,

on reflection, I think your idea is best, since it keeps the
straightforward ok/warning/error status.  I've altered the text so 
that in case of a non-forthcoming recipient response the hub 
should generate a response with samp.status=samp.error and 
samp.code=samp.noresponse.  The change is visible at
http://code.google.com/p/volute/source/detail?r=1544

Mark

On Wed, 13 Jul 2011, Luigi Paioro wrote:

> Well, actually clients code should be ready to receive values other than
> samp.ok, etc. but I'm not sure I've been so careful writing the clients code I
> have. However this is not really an issue for me, since if I find a problem I
> can promptly fix it. I am rather concerned about the code written by others.
> In any case, if I am the only one worried about this, that's OK,
> samp.noresponse is a good option.
> 
> Cheers,
> 
>   Luigi
> 
> 
> Il 07/13/11 17:25, Mark Taylor ha scritto:
> > 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 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/