Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

> I'm not sure I understand what the concept is here.  I was thinking
> more in terms of a type of service, e.g., an image or table viewer
> service/tool, registering with the "hub", after which clients could
> expect it to perform some standard operations defined for that type
> of client, or at least deal with certain classes of data.  Hence Aladin
> would register as an image tool, Topcat and VOPlot as table tools, 
> VOSpec, SPLAT, Specview, etc. as spectral analysis tools, and so forth.
> A client could query the "hub" to find out what tools are available
> to handle a certain type of data.  This would not be enough to describe
> the full capabilities of each service, but there are various ways 
> that could be handled as well.

	As Alasdair says,  Nooooooo!  This sounds like the Solaris 
tooltalk model where an app is specified as a Handler for email, another
for text editing, etc.  Never mind we'd have to define what an "image
tool" is and it's associated message defaults, create a 'ttype' idea,
etc.
	What I had in mind is more the pub-sub model where an app 
registers an interest in say the display.* stream of messages.  Maybe
it's just a logging app, or maybe it's an image display tool, but in
any case it would like to see all of the display-related messages.
It can choose to act on them (perhaps more so if it is specifically
the recipient rather than in a broadcast) or reject a message if say
display.url isn't in its capabilities.  Something like the 
get.capabilities message (or the OFFER idea) is meant to allow one app
to request the specific capabilities of another and perhaps negotiate
for itself who is the most likely image display tool to use.  As the
sending app I might know my votable contains an SSAP spectrum, but if
SPLAT weren't available I could perhaps make do with VOPlot to simply
plot the spectrum since I'd know it had both an X-Y a plotting capability 
and a votable capability.  How complex this gets is entirely up to the
client, if it couldn't find SPLAT it might just exit.  In any case, a
lot of this would likely be done in the interface rather than at the 
client level.



> You seem to be suggesting instead that an application registers that
> it can perform certain types of operations on certain types of data,
> indicated via the mtype.  That could also work; I guess in this case
> one would be registering the individual capabilities, expressed as
> the operations (indicated as mtypes) which the tool supports.  This
> almost starts to sound like a MIME-type application registration
> scheme rather than a messaging system.

	Not at all.  Adding mime types only confuses things in this case
in the same way specifying data types would, i.e. does the type refer t
the argument (e.g. string for the filename) or the data (e.g. FITS)?B 

> 
> I think the concept of MTYPE, or at least how it would be used,
> is still a bit muddy.  

	Not to me 8-)


-Mike