Apps Messaging - Semantics of a Message

[John Taylor]

On 10 Apr 2007, at 11:21, Mark Taylor wrote:

> On Sat, 7 Apr 2007, John Taylor wrote:
>
>> Do any of the Plastic devs have any comments about which style of  
>> messaging
>> they use?  I tend to use synchronous messaging when the reply is  
>> important,
>> but responsiveness isn't (e.g. the metadata gathering case above),  
>> and
>> asynchronous when the reply is unimportant but you want to be  
>> responsive (
>> e.g. sending a row subset for an application to highlight).
>
>> From Java, I'd be happy to use asynchronous messaging at all times;
> it's not all that arduous to build synchronous functionality on top
> of asynchronous primitives, and if you're using a library this
> kind of utility function can be provided.  Your example:
>
>> behaviour could be allowed.  The sort of use case I have in mind  
>> for it is
>> that when an application starts up it might want to message all  
>> the other
>> apps to gather metadata about them (names, descriptions, icons  
>> etc) with
>> which it will populate one of its menus.  If I can send a message
>> synchronously it's much easier to code, and it doesn't really  
>> matter if one
>> of the receiving apps "times out", it will just delay the start up  
>> of ours a
>> little.
>
> is a good one: if synchronicity is built into the protocol then  
> timeouts
> would have to be quite long for the case in which the request is an
> expensive one (load or analyse a large image), and I don't want to  
> delay
> application startup by that kind of timescale (or, indeed, even by a
> few seconds) in the presence of poorly-behaved applications.

In practice I haven't really seen this occurring - partly because my  
Hub unregisters poorly behaving applications (which might not be a  
good thing!)

I don't think there are any insurmountable technical issues with  
either approach.  When we design messages that are intended to do  
something long running then we'd just design them to return  
immediately.  A client using either the asynch or synch message  
dispatch message would find it returned without delay.  There'd be no  
need for long timeouts.

However, there really aren't that many messages that need to return  
results and could be treated synchronously: the application metadata  
ones are the only ones that spring to mind.  If this information was  
stored in the hub and accessible in other ways then I'd have no  
worries at all.

I think it comes down to a question of which is easier for the client  
programmer (see manifesto item 2), and I'm prepared to be persuaded  
that the apparent simplicity offered by synchronous messaging is  
actually an illusion.





>
> So, on the whole, I am in favour of all-asynchronous messaging.
>
> I think the only compelling argument against is for use from  
> environments which would have serious difficulties in processing  
> asynchronous messages,
> i.e. ones which are not multi-threaded and/or only wish to send and
> not to receive messages.  These are not something I've given much
> thought to - does anybody have use cases for such situations where
> a reply is required?

I don't have a very strong one.  I'd quite like this messaging system  
to be simple enough that it's easily accessible from python, IDL and  
other scripting environments.  My feeling is that in most cases the  
sorts of messages you'd be sending would be to do with loading tables  
and showing images - you probably wouldn't be much interested in the  
reply.

John