Apps Messaging - Semantics of a Message

[Doug Tody]

Hi Al -

On Tue, 10 Apr 2007, Alasdair Allan wrote:

> Doug Tody wrote:
>> 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.
>
> Nooooooo! Why would you want to make that sort of arbitrary restriction? For 
> instance Aladin can do interesting things with both tables and images (so can 
> Topcat) but they do different interesting things.

Of course, the same application could then merely register as being
able to work with both types of data.

>> 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.
>
> Yes, that's exactly how I think it should work.
>
>> 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.
>
> Yup, and it's a lot more flexible than the "image tool", "table tool" 
> approach.
>
>> Are we trying to define a standard service model for each major class of 
>> astronomical data?
>
> I really, really hope not. I think that's a doomed exercise.

Ok, thanks for the clarification.  I will have to think about this
more, but getting back to our original question, I guess one would
just want to register the supported mtypes at connect time.  This would
only work for a few reasonably well-defined operations.

It seems to me that we are still defining a standard service model
for each type of data, but just doing it in an adhoc fashion, by
defining operations at random as they need arises (which is, alas,
the way a lot of software is designed).

I wonder what the generic operations for a "data tool" are?  For
example, load; unload; display; display region-of interest (display
zoomed region); select/pick from loaded; query region (user defines
region; similar to a cursor or region mask read); describe; list;
and so forth.  Detailed capabilities, such as for actual analysis,
are probably beyond what can be described generically so that multiple
tools can implement the feature, however messaging could be used to
send tool-specific commands.

In any case, this is not messaging (although it is often used in
conjunction with messaging), but some combination of MIME-type
delegation and object request broker.  The client wants to find out
what capabilities are available from the registered services, and then
send requests to do things.  This is ok, but we shouldn't confuse it
with basic messaging.  Rather it is built on top of basic messaging
(but could still be part of the built-in "hub" services).

 	- Doug