samp.status=samp.noresponse

[Luigi Paioro]

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