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