SAMPY

[Luigi Paioro]

Thank you Mark.

Personally I think so, this should be clarified in sec 3.11.

Well, I'm going to update SAMPY... :)

Luigi


> I think the answer is 2 above - the client's call() or callAndWait()
> should result in an error generated by the hub.
> 
> It shouldn't be 1, since clients might ignore the returned msg-id (in 
> most cases it's not necessary since the msg-tag can be used instead
> to match messages with replies).  In any case that approach wouldn't 
> help for callAndWait.
> 
> It shouldn't be 3 - in general clients should be able to rely on the hub 
> behaving properly even if other clients misbehave in some way; this is 
> in line with the general philosophy that wherever possible the hub 
> should work harder to make life easier for clients.  To put it another 
> way hubs should be coded defensively.  So in this case a hub MUST never 
> send a message to a recipient which has not subscribed to its MType.  In 
> fact this is written explicitly in section 2.4 of
> the spec:
> 
>   6. When the hub receives a message for relaying, pass it on to
>      appropriate recipients which are subscribed to the message's
>      MType. Broadcast messages are sent to all subscribed clients except
>      the sender, messages with a specified recipient are sent to that
>      recipient if it is subscribed.
> 
> A similar question arises with regard to the notify() operation.
> It's less important here since the sender probably doesn't care
> if the message got there or not, but I'd say that in this case
> too an error should result if a notify() is sent to a recipient
> which is not subscribed to the message in question.
> 
> Do you think this should be clarified in the hub method descriptions
> (sec 3.11)?
> 
> Mark
>