Apps Messaging - Semantics of a Message

[John Taylor]

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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070407/a78e206a/attachment.html>