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.