Apps Messaging - Semantics of a Message

[John Taylor]

On 9 Apr 2007, at 21:57, Mike Fitzpatrick wrote:

> Hi John,
>
>> "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.
>
> 	Fair enough.  How do I send a message that says "here's a FITS
> image, a string, and an integer"  (e.g. to call the iraf IMARITH task
> to divide (a string operand) an image (the FITS file) by some number
> (the integer))??  Your idea doesn't make sense to me if more than one
> argument is required.

Hi Mike,
It's not a perfect solution, and I don't claim it's a sensible thing  
to do in all cases, just something that might be useful a lot of the  
time, particularly when you want that Windows-like "right click on a  
file and see a list of appropriate things you can do" functionality.

In this particular case the IMARITH task is presumably quite specific  
to IRAF, and the sending application will know quite a lot of the  
specific detail (it will know to prompt the user for that string and  
integer, or will get them from somewhere else).  So I wouldn't have  
any problem with an

iraf.IMARITH(image, string, integer) message.

However, if it were felt that processing an image is sufficiently  
general that others would want to provide implementations  then how  
about an mtype like

image.fits.process#IMARITH(image, options[])

where options={operator: "/", operand="2"}

The options are specific to the IMARITH task, so the sending app (and  
its user) would have to know something about IRAF and IMARITH, and if  
they get them wrong IRAF will complain, or ignore them.  There are  
things we could do to make life easier though: we can define another  
set of messages that the sending app can use to interrogate IRAF to  
find out what #IMARITH actually means.  IRAF can respond with a human- 
orientated description, an icon to put on menus, even a list of the  
options that this particular message takes that could be used to  
populate a pop-up dialog.


> We could put the above in the argument string
> and let the task figure it out or throw an error (or reject the msg)
> if it can't handle it.
> 	More to the point, the whole reason for this hypothetical message
> is to call a task in the system, why should that be hidden behind some
> data type or implicit in the knowledge that the thing after the '#'  
> is a
> task to invoke and not something else?

Well, I don't mind if we do it IMARITH#process.fits.image instead ;-)

Yes, in the above message the actual task and the data type are given  
equal billing.   We could drop the data type and instead have  
IMARITH#process.image, and pass the FITS type in as a parameter if  
that's sensible.  I think it's more robust to leave it in though.

All I'm trying to do is to keep things loosely coupled by mandating  
the minimum possible and leaving the rest flexible.


>
>
>> 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.
>
> 	My requirement for this system is that I need to be able to invoke
> a task in my command environment.  This is a "great example" of one of
> many hundreds of tasks I might want to call, and users have written  
> their
> own tasks I know nothing about, and I certainly don't have time to  
> wrap
> each one in their own little msg handler.

Certainly not - that sounds unmaintainable.  Equally, we (the group)  
would struggle to create messages that were good matches to all the  
tasks.  Well, I guess if all the tasks are completely different you  
could have a generic exec(string) message, though this would be a bit  
disappointing.  Within IRAF can you get at any metadata describing  
all the tasks (is there some programmatically queryable registry of  
them)?  You could use this to automatically create a list of messages  
to register.


> IDL and other systems will I'm
> sure have the same requirement, so I *do* believe the apps group has a
> place in saying how/whether this requirement will be met.  The problem
> I'm trying to address is more along the lines of adding messaging to
> tcsh so you can invoke a unix command, not calling a method normally
> associated with a GUI widget.

OK, I  can see we have different uses in mind - I'm mostly coming at  
it from a "click 'n' go" perspective.


> 	To use the filtering in a different manner: consider a case where
> you query to see whether IRAF can handle any *.url messages at all, if
> I say 'no' then you might choose to download the URL in your app and
> simply send me the local desktop filename in a task call.

Yes, that's the way I see it working.  Similarly if I've got a  
VOTable and you can only understand FITS, then I could convert it  
before sending it (assuming I'm able to).  You wouldn't necessarily  
need to use wildcards for this though.


>
>
>> 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!
>
> 	So we restrict the wildcards to '*' and '?', or require that
> a get.capabilities message reply with the complete mtype.  Your  
> example
> also assumes that a client declaring 'table.*.url' is using the '*' to
> indicate all possible/accepted defintions of a table, not simply a
> willingness to try to process the message.  Your task B may send its
> votable and my task A is still free to reject it for whatever reason.

Yes, I agree with that - I was just highlighting the potential  
difficulties in the pattern matching approach.


>
>
> -Mike
>
>