Apps Messaging - Semantics of a Message

[John Taylor]

On 7 Apr 2007, at 20:39, Mike Fitzpatrick wrote:

>> > 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.

Hi Mike,

"here's a table" isn't the whole message type, it's just the bit that  
needs to be specified by us to ensure interoperability.  Individual  
apps can then refine that message type further to advertise what they  
would do with a such a table.


>
>> 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.

Well yes, surely you need to know the data type, how to get at the  
data, and what to do with it, before you can take any action?  These  
don't all have to be in the mtype...you could pass the datatype as a  
parameter of the message, but the advantage of it being in the mtype  
is that the receiving application is advertising in advance what data  
types (and retrieval methods) it can deal with.
I'm not sure that we'd need a table.votable.file if we had a  
votable.votable.url, but just supposing we do, then yes, the  
receiving application would do something different on receipt of
table.votable.url#doSomethingCool
and
table.votable.file#doSomethingCool

(in this case the messages probably do the same thing as far as the  
user is concerned...the only difference is how the data gets from A  
to B, so we might want to adopt some convention that allows us to  
reflect this in UIs...but that's not a detail to worry about at this  
stage).



>        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!!

I'm afraid I don't know what this IRAF task does, but superficially  
this looks like a great example of the sort of message type that is  
so application-specific that it's not the apps-group's job to  
standardise it, but would be best left to the IRAF authors.  However,  
if it is generic enough that there are likely to be several  
applications providing this sort of functionality then the apps group  
can define the following mtype [which you can delimit into atoms  
according to taste]

processFitsImage, takes a URI of the input image, returns a URI of  
the output image

and IRAF will declare that it understands

processFitsImage#sqrt
processFitsImage#addSepiaTone
....

Should the industrious IRAF team add another function then all they  
need to do is declare a new #fragment, and all of IRAF's clients will  
magically know about the new feature.  No recompilation required, and  
no work from us.  Now, many of these functions will probably require  
more than just the input file...they probably will need some  
parameters as well.  No problem: we define processFitsImage to take  
an optional struct of parameters.

So
processFitsImage#rotate
will be accompanied by parameters (url=file loc, options=[angle=90])

It's not foolproof - the option list will be specific to each IRAF  
function, and the user  of the sending application will have to read  
IRAF's docs to get the valid parameters.

*Anyway*, this discussion is probably going a bit off-topic - should  
we postpone this till we've got the higher-level decisions sorted  
out?  I'm sure there are plenty of folks currently on long Easter  
breaks who will want to contribute.


>
>
>> 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).
>

I wonder if we're not quite on the same wavelength here.  I see  
clients as declaring to the Hub the message types that they support,  
and this information being available to other clients to do things  
like populate menus appropriately.  If client A declares that it  
supports "table.*.url", then client B will need to parse this  
expression to know that if it has a votable then it can offer the  
user a "send this table to client A" button.    While dealing with  
"table.*.url" isn't too bad, dealing with "table\.[Ff][Ii][Tt][Ss]| 
VOTABLE*\.inline|url" could be a challenge!

(Of course, I also see the hub using the expression to filter messages.)

John