samp.status=samp.noresponse

[Luigi Paioro]

Hi Mark,

   it looks like a good compromise to me.

Cheers,

   Luigi


Il 07/26/11 15:22, Mark Taylor ha scritto:
> 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.