Apps Messaging - Semantics of a Message

[Tony Linde]

I REALLY hate to say this but I agree with Al <spit, spit>.

Let's keep this first attempt at getting apps to cooperate at the simplest
possible level.

Maybe we need to get away from the idea that we're building a messaging
system. Such a thing has too much baggage in the IT arena to do with secure
delivery, message and app identification etc. Why not pitch this as an
application PinBoard. Any application can then choose to post some sort of
notification to the pin board and other applications can choose to receive
notifications which match some pattern. Do we really need any more than that
at this stage?

T.

> -----Original Message-----
> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On 
> Behalf Of Alasdair Allan
> Sent: 06 April 2007 12:18
> To: apps at ivoa.net
> Cc: Mike Fitzpatrick
> Subject: Re: Apps Messaging - Semantics of a Message
> 
> 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.
> 
> 
>