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. Received on 2007-04-06Z13:18:15