samp.status=samp.noresponse

[Luigi Paioro]

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.