Apps Messaging - mtypes

[Doug Tody]

On Tue, 10 Apr 2007, Mark Taylor wrote:

> I think that rationalising the naming along the lines that you suggest
> may be a good idea, but I'm not necessarily in favour of attempting
> to come up with names which are supposed to be machine-parsable.
> I understand the concept of claiming to support "display.*"-type
> messages, but I'm not sure under what circumstances such a claim
> would be useful.  If an application can display FITS, GIF and JPEG images but 
> not other types I don't see that either the receiver or the
> sender benefits from the receiver advertising that it potentially supports 
> display of any kind of image.  Do you have a use case
> illustrating the advantages of parsability of mtypes?

An important use-case for this type of feature is for the case of
publish/subscribe messaging (broadcast of NOTIFY-type messages), where
a client tells the "hub" it wants to subscribe to all "display.*"-type
messages (or whatever class of message).  Typically in this case,
the messages are asynchronous, and the sender does not know or care
what happens to the messages.  A logger or display GUI is a typical
consumer of such messages.

It is a different case if the application "supports" these messages,
i.e., can respond to them as a service, and take some action on
behalf of a client.  These are two different cases: one is classical
publish/subscribe messaging, the other is a class of service, for
example an image display service.  Something like MTYPE could however
be the basis for both.

 	- Doug