Apps Messaging - Semantics of a Message

[Doug Tody]

On Tue, 10 Apr 2007, Mike Fitzpatrick wrote:

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

I think I get the idea, but this is really rather strange.  We would
like to display an image (for example), so we broadcast a display
request to anyone who might be out there, and they all on their own
display the image, or do some other random thing which is similar?
Requests, especially those which perform complex or expensive operations,
are different than e.g., broadcasting Notify events.

One could broadcast to see if some app can handle a certain class of
request (probably this is what you referred to earlier), but it is
probably still better to register capabilities when a tool connects.

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

This is more reasonable.  But you are really just back in the service
model, where a client discovers connected services, and then queries
them for their capabilities.  For this to be useful in general,
one will have to define some generic capabilities which multiple
service/tool instances will implement, and we are back in the object
modeling realm again.


>> 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 did not mean MIME type in a literal sense, but as an analogy, as
in a way to identify applications which can handle a certain class
of data.  A request broker provides a means to find a service/app
which can handle a particular operation (e.g., MTYPE).

 	- Doug