Hi Al,
> 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...
This is why I started by saying the list would 'suffer the same debate..." Any list was gonna be a target so I just tried to cover the different things we (I specifically) might do with the system. Conceptually I wanted to preserve the idea of a NOTIFY, REPLY and REQUEST "type" of message and recognized the REQUEST would be the most controversial.
I agree these should be the most common, and high level, kinds of messages. However, what I had in mind is that an app that connects and claims to support a specific message could use this to advertise a specific capability (consider for example an app that queries for these capabilities and can dynamically build a menu of options). There is also a logical difference between e.g. what image.histogram and table.histogram might require or produce, a simpler 'histogram' message is more general but also too general.
> > event.* UI event messages
> > :
>
> 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.
This was probably an extreme thing to put on the list, and should probably be one of the "unregulated" messages if at all. What I had in mind was an IRAF use-case where a task like IMEXAMINE can do many different things depending on the keystroke typed at a given position (also the reason for the 'exec.task' thing). So, after displaying an image and exec'ing the task, a series of keypress events could be used to create contour plots, radial profiles, etc.
>
> > 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?
get.info get the iconURL for an app a la PLASTIC set.param tell a task what the default SIAP search size is set.property set a 'timeout' property for delivery of msgs to an app get.capabilty request a list of supported mtypes from an app get.appName obvious get.filename get the filename associated with a msg 'refID'
Note there are parallels to some of what the PLASTIC API does.
> > load/save File operations
> > :
> 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.
One app tells another to select a set of rows based on some expression or an explicit list. Then, tell the app to save that subset to a new file. Or, load two tables, crossmatch and save the result. How/whether a 'save' message could be implemented is up to the app, but I can see wanting to do it.
>
> > 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.
There is nothing in these that prevents an app from doing whatever it likes in response to the message, but like I said the specificity has the advantage of advertising something that both a machine can parse easily, and a human developer can interpret as probably doing what is wanted. An app can simply register a "display.*" capability without saying specifically what kinds of display it will do, VOPlot could register with "plot.*" and then maybe it's just a crapshoot for the sending app whether the user gets something reasonable.
> .....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.
That's up to the sender. One could send display.image to a specific image display task, but send the 'highlight.position' to the Any recipient in which case the display task and the UI-less subtle app can do whatever they do.
This discussion of the specific messages is good and necessary but perhaps a separate thread. For the moment I'd like to focus on whether the idea of a UCD-like 'mtype' is worth pursuing or needs more development. Once we agree on that we can fight over the vocabulary.
-Mike Received on 2007-04-07Z07:37:37