luigi at lambrate.inaf.it
Thu Jul 3 02:34:28 PDT 2008
Thank you Mark.
Personally I think so, this should be clarified in sec 3.11.
Well, I'm going to update SAMPY... :)
> 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)?
More information about the apps-samp