callAll() return value

[Mike Fitzpatrick]

It's the Monday morning after an extended trip so maybe I'm
missing something:  the purpose of returning the msg-id in a
call() was so that when the recipient sent a reply() with the ID
the sender would be able to map a reply to the original message.
Don't we lose that if callAll() doesn't provide the msg-id?

Perhaps a simpler solution is for callAll() to return a map containing
both the msg-id and the recipient list (and for convenience maybe even
a count)?  In your scheme I can send two callAll() and perhaps get
back an OK and and ERR from one recipient, but I won't know which
of the messages actually failed.

-Mike


On Mon, Sep 15, 2008 at 9:21 AM, Mark Taylor <m.b.taylor at bristol.ac.uk>wrote:

> Hi gang,
>
> so far in writing JSAMP and SAMPifying TOPCAT I've come across very
> little in the SAMP spec that looks (to me) like it should have been done
> differently, which is good.
>
> However there's one thing which is something of an annoyance and I think
> maybe we should change.  The callAll() hub method is defined:
>
>    string msg-id = callAll(string msg-tag, map message)
>
> where the msg-id is one which is passed to all of the recipients.
> You may recall that the sender does not in general have to examine or
> record the returned msg-id, but may want to use it if it needs
> to discuss the message with one of its recipients at a later stage
> (e.g. by exchanging progress type messages corresponding to the
> earlier message).
>
> What's annoying about this is that you don't know which recipients
> the message was actually sent to.  Given that you are using
> callAll (rather than notifyAll), you presumably care about getting the
> result(s), for instance to update some internal state, or to tell the user
> that messages were or were not sent successfully.  But since there
> is no way of telling for sure how many recipients there were, you can't
> know when responses have been received from them all.
> I have found myself in application code calling getSubscribedClients()
> to find out which recipients will receive a message, then calling
> callAll() to send it, so that I can inform the user when all the
> responses have been received.  This is (a) fiddly and (b) unreliable (since
> clients may un/subscribe between the two calls).
>
> I suggest therefore that callAll() is redefined to return a list of
> recipient-id values, one for each recipient to which the message was sent:
>
>   list recipient-ids = callAll(string msg-tag, map message)
>
> This means that you don't get the msg-id, but as noted above in most
> cases you don't need (or even want) this.  callAll() is a bit of a
> convenience method in any case; in the fairly rare cases that you need to
> get message IDs you can use getSubscribedClients() and make call() calls to
> each recipient by hand at not much extra effort. I can think of various
> alternative schemes to this which would address
> the same issue in various more or less complicated ways, but I'll leave the
> proposal at this one unless it generates further debate.
> If callAll() returns a list of recipient-ids, notifyAll() could I suppose
> do the same, although being a notification the result would probably
> in most cases be discarded.
>
> Since the return value of callAll is probably discarded at present most
> of the time, I doubt this change would affect any code apart from testing
> code which anybody may already have written.
>
> Opinions?
>
> I should note here that in connection with the fact that as callAll()
> stands a single msg-id is returned for multiple messages sent, Alasdair said
> earlier (7 July) that it "feels wrong".  I resisted
> changing it at the time, but I now think his feeling was probably right.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/<http://www.star.bris.ac.uk/%7Embt/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080915/54f080c7/attachment-0001.html>