Apps Messaging - Semantics of a Message

[Alasdair Allan]

Mike,

A good start here, and I'll reply to the rest of your message later,  
but to kick off the discussion I'd like to take issue with the way  
you've conceptualised what the messages we're going to pass actually  
mean...

Mike Fitzpatrick wrote:
> Notify (no response required)
> 	app.*				Application status msgs
> 	    connected
> 	    disconnected
> 	    error
> 	status.*			Reply status messages
> 	    reply
> 	    delivery
> 	    progress
> 		:

Yup, I can see these all being needed.

> 	event.*				UI event messages
> 	    keypress
> 	    mouseButtonDown
> 	    mouseButtonUp
> 		:

I really fundamentally disagree that we should be dealing with UI  
level messages, conceptually you're thinking us into a box here. I  
think the messages should deal with higher level concepts, i.e. "Here  
is an image, do what you want with it" level rather than, "The user  
pushed button A" level.

>     Request (response required)
> 	set/get				Set/Get property messages
> 	    info
> 	    param
> 	    property
> 	    capability
> 	    appName
> 	    result
> 	    filename

Erm, this opens a whole can of worms. I must admit for the internal  
message system for eSTAR I have gone down this route as eSTAR  
epitomises a case where a bundle of ((very) stateful webservices is  
needful. However PLASTIC gets away without carrying state around at  
all (or at least you can design your app not to care). Can you give  
me a use case where we need to ship state around in this manner?

> 	load/save			File operations
> 	    image
> 	    table
> 	    URL

Not sure how you envisage this working. One application tells another  
to save something? That very much depends if both can see the thing  
the first is talking about, which isn't necessarily a given.

> 	plot.*				Vector Graphics capabilities
> 	    table
> 	    rows
> 	display.*			Image Display capabilities
> 	    image
> 	    URL
> 	select.*			Table selection capabilities
> 	    rows
> 	highlight.*			Object highlighting capabilities
> 	    position
> 	    rows

I'd actually like to go with a much looser conceptual design, so  
"Here is an image" and "Here is a table" and "here is a position"  
rather than "Display an image", "Plot a table" and "Highlight a  
position". That way we're really far more flexible, the application  
receiving the message can decide what its best designed to do with  
the data rather than being instructed to do a specific thing. We're  
going to need far fewer messages that way, and it means that the  
application messaging system can support novel and interesting  
applications without having to add half a dozen more messages every  
time you want to do something new. For instance under the above are  
we going to send a message to "display.image" and  
"highlight.position" to one visualisation application, and then a  
different set of messages to another subtly different application  
that doesn't even have a UI perhaps, but would be interested in  
getting an image with an (user defined as interesting) position  
attached. A data mining application perhaps, so "analyse.image" and  
"datamine.position"? Instead of sending 4 messages at that point, we  
could just send 2, "handle.image" and "handle.position".

> 	exec.*				Remote task execution capabilities
> 	    task

Again, not sure how that's going to work (safely). Use cases?

Al.