Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

> > All I can say is that a "here's an image, do something' message to a
> > msg-enabled IRAF is just asking for trouble.  What you describe is a
> > data-sharing interface and not messaging where the messages have any real
> > meaning or predictability for the user.  I would also argue that appending
> > the ivorns is just a verbose variant of the 'root.detail' mtype idea and
> > an example why specificity in messages is needed in the real world.
>
> I think what we're debating is what exactly we need to mandate in this group
> for the messaging to work in the real world and yet still be flexible.
> Forget the ivorns for a moment - the exact format of the message types
> doesn't matter.  What I'm arguing is that we (this group) might define an
> mtype such as:
> table.votable.url as representing a general "here's a table of format
> votable available from a URL".   This contains all the information that a
> sender needs to send the table, and all the information that the receiver
> needs to receive it.  What actually happens to the table isn't any of our
> business.

        I disagree, what possible use is "here's a table" as a message
other than to generate a "so what" reply?  A response to a get.datatype
message might encode the answer this way but the mtype of the reply will
still be status.reply.

> So then IRAF can come along and declare that it understands the
> following mtypes:
>
> table.votable.url#load
> table.votable.url#doSomethingCool.
>
> The part that we defined specifies everything that the applications need in
> order to communicate: there is a table; it's in VOTable format; it's given
> by a URL and here are the parameters.  The part that the IRAF author defines
> adds the detail needed for the sending application to tell its user what to
> expect if such a message is sent.  We don't need to define this in the apps
> group: every application will be different.  These "fragments" will change
> much more rapidly than the apps group-defined part - and why not? nothing
> will break if the do.  Indeed, an application could even create new
> fragments "on the fly" as circumstances change.

        I strongly disagree here:  In this scheme I now need to know that
the combined mtype represents a data type and an action you want me to do
on that data.  What I do would be different if it were table.votable.file
and if doSomethingCool() didn't already know about URLs I'd have to add
that as extra complexity.
        For example, when I first listed the set.param and exec.task mtypes
I had a particular case in mind of calling an IRAF task.  So the messages

        mtype=set.param   args="imfunc.input    foo.fits"
        mtype=set.param   args="imfunc.output   bar.fits"
        mtype=set.param   args="imfunc.function sqrt"
        mtype=exec.task   args="imfunc"

could set the individual parameters and invoke the task  (in IRAF you
can set a parameter as "<task>.<param>=<value>" on the command line,
I realize imfunc.input looks like an mtype but it means the 'input'
param of the 'imfunc' task).  This scheme works to call almost any task
the same way.  If an image were a URL I could download it to a file and
the above stays the same, but implementing 'image.fits.url#imfunc' means
I need separate methods for each task I might call (rather than a generic
callTask()),and things just overall get messy.  I'd point out that here
we have 2 mtypes that let you access literally hundreds of tasks!!


> My feeling is that the pattern matching could be useful, but will also
> complicate things for the client (particularly if we allow patters more
> complicated than "*"), so we'll probably need more debate on this.  As I
> said in my initial response, I think the UCD concept for building up mtypes
> is a good one even without the pattern matching.

        It shouldn't be too bad given that most environments/languages
have some sort of regular expression capability.  Note also that the
matching is done only in the Hub and not the client, i.e.the Hub matches
'display.URL' with apps registered using 'display.*', however the
delivered message contains the full mtype value so it's just a matter
of parsing a dot-delimited string and some string compares (easy even
in Fortran).


-Mike