> 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 Received on 2007-04-11Z01:01:03