Al,
not sure which "all the other methods" you're thinking of, but agreed as Thomas says the order mismatch between call() and receiveCall() is not helpful.
Currently we have
notify (recipient-id, message)
notifyAll (message)
call (recipient-id, message, msg-id)
callAll (message, msg-id)
callAndWait (recipient-id, message)
receiveNotification (sender-id, message)
receiveCall (sender-id, msg-id, message)
Maybe we should rationalise it a bit more and have
notify (message, recipient-id)
notifyAll (message)
call (message, recipient-id, msg-id)
callAll (message, msg-id)
callAndWait (message, recipient-id)
receiveNotification (message, sender-id)
receiveCall (message, sender-id, msg-id)
which looks a bit tidier and less haphazard.
Any opinions? If people are not particularly keen I'm happy to go with Al's original suggestion of just switching msg-id and message in call(), though we should do the same thing in callAll() at the same time (or alternatively just flip them in receiveCall() instead).
Mark
On Wed, 7 May 2008, Thomas Boch wrote:
> Hi,
>
> As the signature of receiveCall is receiveCall(string sender-id, string
> msg-id, map message) , it makes sense indeed for consistency to change
> the signature of call to :
> call(string recipient-id, string msg-id, map message)
>
> as you are suggesting.
>
> Thomas
>
> Alasdair Allan wrote:
>>
>> Just noticed that call( ) (see p19, section 3.10) is the odd method
>> out, with a prototype of
>>
>> call(string rcepient-id, map message, string msg-id )
>>
>> which is the other way round to all the other methods. Should this
>> instead be,
>>
>> call(string rcepient-id, string msg-id, map message)
>>
>> like the rest? If not, is there a reason why its different?
>>
>> Cheers,
>> Al.
>
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-05-12Z12:53:25