On 4/6/07, Alasdair Allan <aa-at-astro.ex.ac.uk> wrote:
>
>
>
> > 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.
I both agree and disagree. I'd hope that in general people would opt for higher level messages since "the user clicked at pixel (104,39)" is not going to be very interoperable. However, if there is a use case for it (suggestions?), then all Mike is doing is providing the vocabulary to form the mtype.
[]
> 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".
Yes, as per my previous email, I see a benefit in going for quite general data-centric mtypes that can be annotated by the receiving application to specify what is actually going to be done with the data in the message.
> exec.* Remote task execution capabilities
> > task
>
> Again, not sure how that's going to work (safely). Use cases?
I think both Thomas (B) and Mark (T) can provide a couple. Thomas collaboration with Igor has recently thrown up a case where Igor needed to get at Aladin's scripting interface. I think they did that through an Aladin-specific "exec this code" message. Obviously it's to be avoided if possible as it reduces interoperability (as well as opening the door to "exec rm -r *" in some cases).
Al.
>
>
>
Received on 2007-04-07Z01:49:28