Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

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


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


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


-Mike